* [LSF/MM TOPIC] Inline encryption support for block devices
@ 2016-12-16 17:32 Theodore Ts'o
2017-01-06 22:29 ` David Howells
2017-01-12 13:36 ` Lukas Czerner
0 siblings, 2 replies; 6+ messages in thread
From: Theodore Ts'o @ 2016-12-16 17:32 UTC (permalink / raw)
To: linux-fsdevel; +Cc: lsf-pc
Many embedded SOC's are using in-line encryption engines (ICE) to
accelerate encryption to storage devices. The way they work is that
the ICE unit is located between the memory and the flash or other
storage device, and when the OS submits the I/O, it includes an
encryption key identifier, indicating which key (out of a small number
that have been loaded into the ICE hardware) should be used. The
hardware then takes care of doing the encryption without needing to
keep the CPU busy doing the encryption, and without needing to use
bounce buffers when writing encrypted blocks.
There have been proposals to add this before[1]. However, those
changes were fatally flawed since they completely bypassed the block
layer, assumed that the device driver could derference the
page->private pointer passed to it via the bio structure, assume it
was a buffer_head pointer, then dereference b_assoc_map pointer to
find the underlying file system inode, and then assume the inode
belonged to ecryptfs, and then grab the key to be used out of
ecryptfs's specific inode structure.
[1] https://lkml.org/lkml/2015/11/8/70
Support for file system based encryption[2] is in the Pixel and Pixel
XL devices, Google's flagship Android devices, and it provides the
basis for the Direct Boot API[3]. Originally, ICE was not intended to
enabled for use in the Pixel and Pixel XL devices. Unfortunately, due
to performance concerns, a crash implementation was needed[4], and so
Android had to bypass its policy of preferring upstream first
development for core kernel features.
[2] https://source.android.com/security/encryption/file-based.html
[3] http://www.androidcentral.com/android-70-what-direct-boot
[4] https://android-developers.googleblog.com/2016/11/pixel-security-better-faster-stronger.html
We had to take some short-cuts while implementing this support, but we
at least passed the information about which encryption key to use via
the struct bio, instead of peaking in private powers where device
drivers had no business looking at. However, what landed for the
Pixel devices was definitely not what I would consider a clean design,
and it's time to try to clean this up for upstream use. Fortunately,
Michael Halcrow has a team of eager programmers to work on this, and
so I'd like to talk about what the design should look like when we try
to get this work upstream.
Passing a key slot identifer in the struct bio is relatively
straightforward. The trick is in the API between the file system and
the block device to determine which key slot should be used, given the
desired key that the fs/crypto layer would like to use. Also, there
is the question of how to negotiate which encryption suite should be
used, for those ICE implementations that might allow the use of more
than one encryption suite.
Furthermore, I would like to future proof the design to handle
scenarios where the OS does not have access to the keying information
at all, but instead passes a key identifier to the block device, and
then block device would then pass the key identifier to a secure
hardware element such ARM Trustzone, which would then load the key
into the Inline Crypto Engine. This would allow us to answer
criticisms[5] that while the key is secure while the device is off, the
key is still in the host OS memory while the device after the user has
entered her password or PIN, and then has locked her phone.
[5] https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/
Finally, since it may be challenging to get device drivers which
support ICE upstream, and since it would be desireable to be able to
test ICE support using KVM or GCE without having access to ICE
hardware, I'd like to discuss adding support either dm-crypto or some
dm-crypt like block device layer, and then moving the encryption code
in fs/crypto into the block device layer. One thing that I would
like, however, is to allow userspace to be able to mount the "bare"
block device (e.g., /dev/sdc3), but then have the crypto-enabled block
device layer be spliced into the storage stack without having to
require userspace code to first run dmsetup, and then mount a
/dev/dm-X device. I suspect this request will be at least somewhat
controversial, but it would make for a much more pleasant user
experience for fs/crypto users, so I'd very much like to see if we can
accomplish this in a clean way.
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LSF/MM TOPIC] Inline encryption support for block devices
2016-12-16 17:32 [LSF/MM TOPIC] Inline encryption support for block devices Theodore Ts'o
@ 2017-01-06 22:29 ` David Howells
2017-01-24 22:55 ` Michael Halcrow
2017-01-12 13:36 ` Lukas Czerner
1 sibling, 1 reply; 6+ messages in thread
From: David Howells @ 2017-01-06 22:29 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: dhowells, linux-fsdevel, lsf-pc
Theodore Ts'o <tytso@mit.edu> wrote:
> Many embedded SOC's are using in-line encryption engines (ICE) to
> accelerate encryption to storage devices. The way they work is that
> the ICE unit is located between the memory and the flash or other
> storage device, and when the OS submits the I/O, it includes an
> encryption key identifier, indicating which key (out of a small number
> that have been loaded into the ICE hardware) should be used. The
> hardware then takes care of doing the encryption without needing to
> keep the CPU busy doing the encryption, and without needing to use
> bounce buffers when writing encrypted blocks.
I would be interested in joining this discussion as I've been working on
keyrings and crypto facilities inside the kernel.
David
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LSF/MM TOPIC] Inline encryption support for block devices
2017-01-06 22:29 ` David Howells
@ 2017-01-24 22:55 ` Michael Halcrow
2017-01-24 23:16 ` [Lsf-pc] " James Bottomley
0 siblings, 1 reply; 6+ messages in thread
From: Michael Halcrow @ 2017-01-24 22:55 UTC (permalink / raw)
To: David Howells; +Cc: Theodore Ts'o, linux-fsdevel, lsf-pc
On Fri, Jan 6, 2017 at 2:29 PM, David Howells <dhowells@redhat.com> wrote:
>
> Theodore Ts'o <tytso@mit.edu> wrote:
>
> > Many embedded SOC's are using in-line encryption engines (ICE) to
> > accelerate encryption to storage devices. The way they work is that
> > the ICE unit is located between the memory and the flash or other
> > storage device, and when the OS submits the I/O, it includes an
> > encryption key identifier, indicating which key (out of a small number
> > that have been loaded into the ICE hardware) should be used. The
> > hardware then takes care of doing the encryption without needing to
> > keep the CPU busy doing the encryption, and without needing to use
> > bounce buffers when writing encrypted blocks.
>
> I would be interested in joining this discussion as I've been working on
> keyrings and crypto facilities inside the kernel.
I led the ext4 encryption work and made the changes for ext4 encryption
to use ICE on Android, so I'd like to participate in this discussion too.
Note that I also have a CFP proposal submitted through the web site
pending.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LSF/MM TOPIC] Inline encryption support for block devices
2016-12-16 17:32 [LSF/MM TOPIC] Inline encryption support for block devices Theodore Ts'o
2017-01-06 22:29 ` David Howells
@ 2017-01-12 13:36 ` Lukas Czerner
2017-01-12 16:58 ` Theodore Ts'o
1 sibling, 1 reply; 6+ messages in thread
From: Lukas Czerner @ 2017-01-12 13:36 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-fsdevel, lsf-pc
On Fri, Dec 16, 2016 at 12:32:19PM -0500, Theodore Ts'o wrote:
> Many embedded SOC's are using in-line encryption engines (ICE) to
> accelerate encryption to storage devices. The way they work is that
> the ICE unit is located between the memory and the flash or other
> storage device, and when the OS submits the I/O, it includes an
> encryption key identifier, indicating which key (out of a small number
> that have been loaded into the ICE hardware) should be used. The
> hardware then takes care of doing the encryption without needing to
> keep the CPU busy doing the encryption, and without needing to use
> bounce buffers when writing encrypted blocks.
There is hardware to accleerate compression as well. I do not expect it
to require more than ICE (likely much less considering key management
encryption requires), but we should keep in mind that any support or
potential api we'll have might get used by compression as well. So I'd
like to be part of this discussion on LSF.
Thanks!
-Lukas
>
> There have been proposals to add this before[1]. However, those
> changes were fatally flawed since they completely bypassed the block
> layer, assumed that the device driver could derference the
> page->private pointer passed to it via the bio structure, assume it
> was a buffer_head pointer, then dereference b_assoc_map pointer to
> find the underlying file system inode, and then assume the inode
> belonged to ecryptfs, and then grab the key to be used out of
> ecryptfs's specific inode structure.
>
> [1] https://lkml.org/lkml/2015/11/8/70
>
> Support for file system based encryption[2] is in the Pixel and Pixel
> XL devices, Google's flagship Android devices, and it provides the
> basis for the Direct Boot API[3]. Originally, ICE was not intended to
> enabled for use in the Pixel and Pixel XL devices. Unfortunately, due
> to performance concerns, a crash implementation was needed[4], and so
> Android had to bypass its policy of preferring upstream first
> development for core kernel features.
>
> [2] https://source.android.com/security/encryption/file-based.html
> [3] http://www.androidcentral.com/android-70-what-direct-boot
> [4] https://android-developers.googleblog.com/2016/11/pixel-security-better-faster-stronger.html
>
> We had to take some short-cuts while implementing this support, but we
> at least passed the information about which encryption key to use via
> the struct bio, instead of peaking in private powers where device
> drivers had no business looking at. However, what landed for the
> Pixel devices was definitely not what I would consider a clean design,
> and it's time to try to clean this up for upstream use. Fortunately,
> Michael Halcrow has a team of eager programmers to work on this, and
> so I'd like to talk about what the design should look like when we try
> to get this work upstream.
>
> Passing a key slot identifer in the struct bio is relatively
> straightforward. The trick is in the API between the file system and
> the block device to determine which key slot should be used, given the
> desired key that the fs/crypto layer would like to use. Also, there
> is the question of how to negotiate which encryption suite should be
> used, for those ICE implementations that might allow the use of more
> than one encryption suite.
>
> Furthermore, I would like to future proof the design to handle
> scenarios where the OS does not have access to the keying information
> at all, but instead passes a key identifier to the block device, and
> then block device would then pass the key identifier to a secure
> hardware element such ARM Trustzone, which would then load the key
> into the Inline Crypto Engine. This would allow us to answer
> criticisms[5] that while the key is secure while the device is off, the
> key is still in the host OS memory while the device after the user has
> entered her password or PIN, and then has locked her phone.
>
> [5] https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/
>
> Finally, since it may be challenging to get device drivers which
> support ICE upstream, and since it would be desireable to be able to
> test ICE support using KVM or GCE without having access to ICE
> hardware, I'd like to discuss adding support either dm-crypto or some
> dm-crypt like block device layer, and then moving the encryption code
> in fs/crypto into the block device layer. One thing that I would
> like, however, is to allow userspace to be able to mount the "bare"
> block device (e.g., /dev/sdc3), but then have the crypto-enabled block
> device layer be spliced into the storage stack without having to
> require userspace code to first run dmsetup, and then mount a
> /dev/dm-X device. I suspect this request will be at least somewhat
> controversial, but it would make for a much more pleasant user
> experience for fs/crypto users, so I'd very much like to see if we can
> accomplish this in a clean way.
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LSF/MM TOPIC] Inline encryption support for block devices
2017-01-12 13:36 ` Lukas Czerner
@ 2017-01-12 16:58 ` Theodore Ts'o
0 siblings, 0 replies; 6+ messages in thread
From: Theodore Ts'o @ 2017-01-12 16:58 UTC (permalink / raw)
To: linux-fsdevel, lsf-pc
On Thu, Jan 12, 2017 at 02:36:54PM +0100, Lukas Czerner wrote:
>
> There is hardware to accleerate compression as well. I do not expect it
> to require more than ICE (likely much less considering key management
> encryption requires), but we should keep in mind that any support or
> potential api we'll have might get used by compression as well. So I'd
> like to be part of this discussion on LSF.
The thing that makes compression tricky is that the size of the input
data and output data is different. And with in-line crypto, the
premise that you send plaintext to the device driver, which sends it
to the hardware controller, and it gets encrypted before it's passed
to the storage device.
I'm not aware of any compression engines that work in a similar way.
If someone were to do that, presumably it would have return
information back to the file system about how many sectors were
actually written to.
Most of the hardware compression engines work today much like hardware
accelerated crypto, and could use the existing asynchronous crypto
interface. If the file system wants to know how much space the
compressed space used, so it can decide where on the storage device to
place the data. So it becomes tricky to do that in the context of an
off-load compression engine, unless it has on-board buffering so that
it becomes a two-phase process. First you send it to the compression
engine, it tells you how much it was able to compress it, and then you
send a command asking it to send it on to the storage device by
handing it a vector of start sector and lengths.
So it might not have a lot of commonality with ICE as we currently see
as shipping hardware.
Cheers,
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-24 23:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-16 17:32 [LSF/MM TOPIC] Inline encryption support for block devices Theodore Ts'o
2017-01-06 22:29 ` David Howells
2017-01-24 22:55 ` Michael Halcrow
2017-01-24 23:16 ` [Lsf-pc] " James Bottomley
2017-01-12 13:36 ` Lukas Czerner
2017-01-12 16:58 ` Theodore Ts'o
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).