Re: [LSF/MM TOPIC] Memory Encryption on top of filesystems

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Tue, Feb 12, 2019 at 07:31:37PM -0800, Dan Williams wrote:
> > fscrypt encrypt/decrypt is already done at the filesystem/bio
> > interface layer via bounce buffers - it's not a great stretch to
> > push this down a layer so that it can be offloaded to the underlying
> > device if it is hardware encryption capable. fscrypt would really
> > only be used for key management (like needs work to support
> > arbitrary hardware keys) and in filesystem metadata encryption (e.g.
> > filenames) in that case....
> 
> Thanks, yes, fscrypt needs a closer look. As far I can see at a quick
> glance fscrypt has the same physical block inputs for the encryption
> algorithm as MKTME so it seems it could be crafted as a drop in
> accelerator for fscrypt for pmem block devices.

Yes, and in fact this would solve another problem that is currently
being solved in an adhoc fashion, and that's where the
encryption/decryption engine is located between the storage device and
the DMA controller.  This is called an Inline Crypto Engine (ICE), and
it's been done on many mobile devices.

For fscrypt, we want to use to use a different key for each file,
where the per-file key is derived from the per-user key.  (This allows
mutually suspicious users to share a single Chrome OS device; so for
example, if Alice is logged in, she can access her files, but she
willt not be able to access Bob's file.)

So that means we need to pass a key selector (a small integer) into
the struct bio, so that it can be passed to encryption engine.  And we
will need an interface that can either be plumbed through the block
layer or through the memory co ntroller where we can upload a key to
the controller, and get back a key selector which can be passed to an
I/O request.   (Or mapped to a persistent memory range.)

The other important question is how to generate the per-block
Initialization Vector (IV).  There are two ways of doing this; one is
to base the IV on the logical block #, and the other is to base the IV
based on the physical block #.  Normally, fscrypt uses a logical block
number; this allows a file to be defragged, or for the block to be
moved (which is often required for log-structured file systems).  For
the ICE use case, we can't read or write the block without the data
passing through the IV, and it's painful to figure out how to get
logical block number to the ICE, so what the mobile handsets have been
doing is to let the ICE deal with generating the IV, since it has
access to the LBA number since it's located between the flash device
and the DMA engine.

I would imagine that the simple thing to do here for persistent memory
is to base the IV on the persistent memory address for the page.

Cheers,

						- Ted