Re: [RFC PATCH] dm-inlinecrypt: add target for inline block device encryption

[Christoph Hellwig <hch@infradead.org>]

On Fri, Oct 04, 2024 at 09:21:47PM +0200, Milan Broz wrote:
> 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.

As should any other stackable crypto driver, so that's not an argument
per se.  Allowing to bypass encryption in a lower layer is simply
broken, no matter what you call the target.

> (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).

Now code complexity is an absolute valid argument. I think it should be
weighted very carefully vs a confusing user interface that requires the
user to know if there is hardware acceleration or not.