On Mon, Oct 07, 2024 at 10:25:56AM +0200, Milan Broz wrote: > I am talking from the security point of view. Now, dm-crypt does not trust > storage devices. Storage devices will never see plaintext (or key). > With inline crypto, it needs to see both. With inline crypto as implemented right now the actual storage device does not see the plaintext and key, only the storage controller that is part of the SOC that Linux runs on. > My goal is to mitigate these risks completely with dm-crypt, while clearly > saying dm-inlinecrypt will have a different threat model. > > (Yes, if inline crypto is used through crypto API, we have the same problem, > but you can mitigate it by turning off specific crypto modules.) That same could be done by requiring an explicit opt-in for using inline crypto. But yes, at that point just using a different target should not be a major inconvenience. > I see several self-encryption hardware where it was so broken that vendors > basically say, "use sw crypto" but this will not stop users from using it > in a broken state. Well, with the crazy mess that the TCG storage specs are the quality of implementation of key management or even crypto algorithms that is everything but unexpected. One important feature of inline crypto engines is that they can't just do key management or pick their algorithms and you can always validate the ciphertext vs that done by software, something that can't work with the broken Opal-like full disk encryption model. Anyway, not wanting to second guess you here, just throwing in my 2 cents.
