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.
