Hi Eric,
On 10/18/2024 8:22 AM, Adrian Vovk wrote:
Hello,
On 10/16/24 19:27, Eric Biggers wrote:
From: Eric Biggers <ebigg...@google.com>
Add a new device-mapper target "dm-inlinecrypt" that is similar to
dm-crypt but uses the blk-crypto API instead of the regular crypto API.
This allows it to take advantage of inline encryption hardware such as
that commonly built into UFS host controllers.
Wow! Thank you for this patch! This is something we really want in
systemd and in GNOME, and I came across this patchset on accident while
trying to find a way to get someone to work on it for us.
The table syntax matches dm-crypt's, but for now only a stripped-down
set of parameters is supported. For example, for now AES-256-XTS is the
only supported cipher.
dm-inlinecrypt is based on Android's dm-default-key with the
controversial passthrough support removed.
That's quite unfortunate. I'd say this passthrough support is probably
the most powerful thing about dm-default-key.
Could you elaborate on why you removed it? I think it's a necessary
feature. Enabling multiple layers of encryption stacked on top of each
other, without paying the cost of double (or more...) encryption, is
something we really want over in userspace. It'll enable us to stack
full-disk encryption with encrypted /home directories for each user and
then stack encrypted per-app data dirs on top of that. I'd say that the
passthrough support is more important for us than the performance
benefit of using inline encryption hardware.
Without a solution to layer encryption we can't do a lot of good things
we want to do in userspace.
As far as I understand, the passthrough support was controversial only
because previous upstreaming attempts tried to punch holes into dm-crypt
to make this work. I don't know of an attempt to upstream dm-default-key
as-is, with passthrough support. As far as I can tell, people even
seemed open to that idea...
Is there some context I'm missing? Information would be appreciated.
Note that due to the removal
of passthrough support, use of dm-inlinecrypt in combination with
fscrypt causes double encryption of file contents (similar to dm-crypt +
fscrypt), with the fscrypt layer not being able to use the inline
encryption hardware. This makes dm-inlinecrypt unusable on systems such
as Android that use fscrypt and where a more optimized approach is
needed.
Yeah, sadly you've removed the use-case we're very interested in.
Generic PC hardware doesn't have blk-crypto hardware as far as I can
tell, so we don't get the performance benefit of replacing dm-crypt with
dm-inlinecrypt. However, we do get the performance benefit of the
passthrough support (if we run this on top of the blk-crypto software
emulation mode, for instance)
Best,
Adrian Vovk
It is however suitable as a replacement for dm-crypt.
Signed-off-by: Eric Biggers <ebigg...@google.com>
Is there any plan to update this series ? IPQ9574 needs this
dm-inlinecrypt driver for secure eMMC feature.
Thanks,
Alam.
