On Thu, Oct 31, 2019 at 10:57:13AM -0700, Christoph Hellwig wrote: > On Mon, Oct 28, 2019 at 12:20:26AM -0700, Satya Tangirala wrote: > > We introduce blk-crypto, which manages programming keyslots for struct > > bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with > > the encryption key, algorithm and data_unit_num; they don't have to worry > > about getting a keyslot for each encryption context, as blk-crypto handles > > that. Blk-crypto also makes it possible for layered devices like device > > mapper to make use of inline encryption hardware. > > > > Blk-crypto delegates crypto operations to inline encryption hardware when > > available, and also contains a software fallback to the kernel crypto API. > > For more details, refer to Documentation/block/inline-encryption.rst. > > Can you explain why we need this software fallback that basically just > duplicates logic already in fscrypt? As far as I can tell this fallback > logic actually is more code than the actual inline encryption, and nasty > code at that, e.g. the whole crypt_iter thing. One of the reasons I really want this is so I (as an upstream maintainer of ext4 and fscrypt) can test the new code paths using xfstests on GCE, without needing special pre-release hardware that has the ICE support. Yeah, I could probably get one of those dev boards internally at Google, but they're a pain in the tuckus to use, and I'd much rather be able to have my normal test infrastructure using gce-xfstests and kvm-xfstests be able to test inline-crypto. So in terms of CI testing, having the blk-crypto is really going to be helpful. - Ted
