Re: [PATCH v13 00/12] Inline Encryption Support

On Fri, May 15, 2020 at 10:00:59AM -0700, Eric Biggers wrote:

The fallback is actually really useful.  First, for testing: it allows all the
filesystem code that uses inline crypto to be tested using gce-xfstests and
kvm-xfstests, so that it's covered by the usual ext4 and f2fs regression testing
and it's much easier to develop patches for.  It also allowed us to enable the
inlinecrypt mount option in Cuttlefish, which is the virtual Android device used
to test the Android common kernels.  So, it gets the kernel test platform as
similar to a real Android device as possible.

Ideally we'd implement virtualized inline encryption as you suggested.  But
these platforms use a mix of VMM's (QEMU, GCE, and crosvm) and storage types
(virtio-blk, virtio-scsi, and maybe others; none of these even have an inline
encryption standard defined yet).  So it's not currently feasible.

Not that you don't need to implement it in the hypervisor.  You can
also trivially wire up for things like null_blk.

Second, it creates a clean design where users can just use blk-crypto, and not
have to implement a second encryption implementation.

And I very much disagree about that being a clean implementation.  It is
fine if the user doesn't care, but you should catch this before hitting
the block stack and do the encryption there without hardware blk-crypt
support.