On Wed, Jul 20, 2022 at 11:49:07PM -0700, Eric Biggers wrote: > I'm glad to see a proposal in this area -- this is something that is greatly > needed. Chrome OS is looking for something like "dm-crypt with inline crypto > support", which this should work for. Android is also looking for something > similar with the additional property that filesystems can override the key used. Yes, this is exciting to see proposals in this area. In ChromeOS we were contemplating ways to upstream Eric's work for Android. This solution should work generally for our use-case, however I would like to add a few extra pieces we were considering. One thing we were looking for is having an option to pass inline encryption keys via keyrings, similarly to how dm-crypt allows suuplying keys both ways: raw and keyring attached. I would assume that is something that should still be possible with the IOCTL-based approach, though proposed API can make it a bit obscure. I was wondering whether there should be a separate field to allow this kind of differentiation? The other aspect is the key lifetime. Current implementation doesn't allow to unset the key once set. This is something that would still work with dm setups, presumably, since the key lifetime is tied to the lifetime of the device itself, but may render problematic if this is applied to a raw device or partition of a raw device, I would assume - allowing no ways to rotate the key without reboot. I am not sure if this is a particularly important issue, but something that I wanted to raise for the discussion. This also becomes relevant in the context of the keyring usages, i.e. whether to revoke the key from the block device when the key is removed from the keyring, or assume it is bound at the time of device setup. The dm-crypt follows the latter model, AFAIU, and it is fine to keep it consistent, but then the question comes back to inability to remove the key in the current API in general. And speaking about dm, the other thing we were looking into is compatibility of inline encryption key setup with dm stacks. Current kernel implementaiton propagates the crypto context through linear and flakey target, we also had initial tests enabling it on thin pools by adding DM_TARGET_PASSES_CRYPTO, which didn't show any problems at first glance (but more testing is required). We believe that an ability to setup multiple different dm targets with different keys over the same physical device is an important use case - and as far as I can tell proposed approach supports it, but wanted to highlight that as well. --Daniil -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
