On 3/13/2026 11:27 PM, Milan Broz wrote:
> On 3/13/26 2:25 PM, Mikulas Patocka wrote:
>> On Thu, 12 Mar 2026, Eric Biggers wrote:
>>
>>> On Wed, Mar 04, 2026 at 04:17:27AM -0800, Linlin Zhang wrote:
>>>> From: Eric Biggers <[email protected]>
>>>>
>>>> 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.
>
> ...
>
>>> I don't think it's plausible that this new patch was actually tested.
>>> The version I sent in 2024 was tested at the time
>>> (https://lore.kernel.org/r/[email protected]/),
>>> but I see at least two things that would make this new patch not work.
>
> What a waste of time... thanks.
>> OK. I dropped it.
>
> Well, the inline crypt has some advantages to proprietary internal
> hw implementations (like self-encrypting drives) - it can be actually
> validated
> comparing to sw version.
>
> Anyway, Mikulas, if this dm-inlinecrypt returns one day, please be
> sure that we do not have security-related "regressions" like not supporting
> keyring. There is no need for dm-inlinecrypt to keep key inside the mapping
> table.
> The keyring code is in dm-crypt, it should be easy to adapt it here.
>
> Thanks,
> Milan
>
Thanks for your review.
I understood that supporting keyring here is to ensure no raw key exposed to
dm table. As implied by the name dm-inlinecrypt, the key used by dm-inlinecyrpt
is a wrapped key, rather raw key. Can we keep the wrapped key inside the mapping
table?
In other word, can dm-inlinecrypt support both keyring and hex key(key in
mapping
table)?
Thanks,
Linlin
