On 10/4/24 8:48 PM, Eric Biggers wrote:
On Thu, Oct 03, 2024 at 10:44:07PM -0700, Christoph Hellwig wrote:
On Thu, Oct 03, 2024 at 05:41:52PM -0700, Eric Biggers wrote:
From: Eric Biggers <ebiggers@xxxxxxxxxx>
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.
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.
Maybe I'm stepping into a mine-field here, but if this simply uses
blk-crypto to accellerate a subset of dm-crypt, why isn't dm-crypt
simply enhanced to use blk-crypto when available?
compatible,
Milan Broz (cryptsetup maintainer) has said that he prefers a separate dm
target. See
https://lore.kernel.org/dm-devel/9ef95bbc-4eee-4c00-f199-0daa3cdd03ed@xxxxxxxxx/
That was a couple years ago though, and this discussion seems to have gone
around in a circle. Maybe things have changed.
There was another discussion recently. I also discussed this with Mikulas
as DM maintainer, and we agreed this is the best way.
Extending dm-crypt is possible, but the dm-crypt threat model should not allow
pushing plaintext down the level.
(I am currently investigating several issues with Opal hw encryption that just
cannot happen with sw dm-crypt. We opened can of worms supporting it in LUKS. :)
Actually, I like the inline encryption logic (and the sw fallback), just I would
prefer we clearly separate the code here (and dm-crypt is already complicated enough).
A dm-crypt extension sounds fine to me too, though keep in mind there will
eventually be inline crypto exclusive features such as hardware-wrapped keys.
Milan
