Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys
Linlin Zhang <[email protected]>
| Newsgroups | dev.linux.lists.dm-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 5/18/2026 8:37 PM, Mikulas Patocka wrote: > > > On Mon, 18 May 2026, Linlin Zhang wrote: > >> >> >> On 5/16/2026 8:17 PM, Milan Broz wrote: >>> On 5/16/26 1:50 PM, Linlin Zhang wrote: >>>> Add support for hardware-wrapped encryption keys to the >>>> dm-inlinecrypt target. >>>> >>>> Introduce a new parameter <is_wrappedkey> to indicate whether >>>> the provided key is a raw key or a hardware-wrapped key. Based >>>> on this flag, the appropriate blk-crypto key type is selected >>>> when initializing the key. >>>> >>>> This allows dm-inlinecrypt to work with hardware that requires >>>> keys to be wrapped and managed by the underlying inline >>>> encryption engine. >>>> >>>> Update the target argument parsing accordingly and pass the >>>> key type to blk_crypto_init_key(). Documentation is also >>>> updated to reflect the new parameter and usage. >>>> >>>> Signed-off-by: Linlin Zhang <[email protected]> >>>> --- >>>> .../device-mapper/dm-inlinecrypt.rst | 10 ++- >>>> drivers/md/dm-inlinecrypt.c | 71 +++++++++++-------- >>>> 2 files changed, 50 insertions(+), 31 deletions(-) >>>> >>>> diff --git a/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst b/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst >>>> index c71e600efb76..3a4ce2c5f228 100644 >>>> --- a/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst >>>> +++ b/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst >>>> @@ -10,7 +10,7 @@ https://docs.kernel.org/block/inline-encryption.html >>>> Parameters:: >>>> - <cipher> <key> <iv_offset> <device path> \ >>>> + <cipher> <key> <is_wrappedkey> <iv_offset> <device path> \ >>>> <offset> [<#opt_params> <opt_params>] >>> >>> Please use optional parameter. >>> Adding mandatory field will introduce unnecessary incompatibility with dm-crypt mappings. >>> (The idea was that you can simply switch "crypt" to "inlinecrypt" for raw keys.) >>> >>> I would probably just add "hw-wrapped" or "keytype=raw|hw-wrapped" optional argument >>> (with raw as default, so no need so specify it). >>> >>> IOW the mapping will look like this (1 is number of optional parameters): >>> >>> <cipher> <key> <iv_offset> <device path> <offset> 1 hw-wrapped >>> or >>> <cipher> <key> <iv_offset> <device path> <offset> 1 keytype=hw-wrapped >> >> >> Thanks for your suggestion! >> >> I agree that keeping "hw-wrapped" or "keytype=raw|hw-wrapped" as an optional >> argument helps preserve compatibility when switching from "crypt" to >> "inlinecrypt" >> >> My concern is that, in practice, this optional argument may effectively become >> mandatory for certain configurations. For instance, "hw-wrapped" or >> "keytype=raw|hw-wrapped" must be set for a wrapped key. This slightly blurs the >> original intent of "optional arguments", which are typically expected to be >> truly optional for correct operation. >> >> Would this be acceptable? which one is more acceptable for upstream? >> incompatibility semantics mappings b/w dm-crypt and dm-inlinecrypt or blur >> the original intent of "optional arguments"? >> >> Any additional thoughts or feedback from others would be much appreciated. Thanks! > > Hi > > I would prefer an optional argument "keytype:raw" or "keytype:hw-wrapped". > Device mapper targets use colon to separate arguments from values, so I > would use it here too. Thanks for the comment! ACK. I'll send a new patch with such modification. > > I removed the patch that always sets BLK_CRYPTO_KEY_TYPE_HW_WRAPPED from > the linux-dm repository and I will accept a patch that introduces > "keytype:hw-wrapped" when you send it. > > Mikulas > >>> >>> The second option will allow to add new key type much easier. >> >> Regarding the second option ("keytype=..."), I agree it is more extensible. >> Could you please clarify what other key types you envision supporting in the >> future? >> >>> >>> Please check how other targets implement it, some dm-crypt examples >>> https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt >>> >>> Thanks, >>> Milan >>> >>