[dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt

Israel Rukshin israelr at nvidia.com
Mon Jan 17 14:00:59 UTC 2022


On 1/17/2022 12:50 PM, Milan Broz wrote:
> On 17/01/2022 08:52, Christoph Hellwig wrote:
>> On Fri, Jan 14, 2022 at 09:51:20PM +0100, Milan Broz wrote:
>>> I think dm-crypt should stay as SW crypto only (using kernel crypto 
>>> API,
>>> so HW acceleration is done through crypto drivers there).
>>>
>>> A cleaner solution is to write a much simpler new dm-crypt-inline 
>>> target,
>>> which will implement only inline encryption.
>>> (And userspace can decide which target to use.)
>>> Code should be just an extension to the dm-linear target, most
>>> of dm-crypt complexity is not needed here.
>>
>> Why do we even need a dm target for this as well?  There should be no
>> need to clone or remap bios, so I think hamdling inline crypto should be
>> just a small addition to the core block layer.
>
> Well, yes, that was my question too :-)
>
> Maybe there is need to have some new userspace utility to configure that
> but otherwise I think that for inline encryption device mapper layer
> only increases complexity and reduces IO performance.
>
Regarding performance degradation, I added only one if condition at the 
data path (inside #ifdef).
> Could anyone elaborate what it the reason for such DM extension?
> Compatibility with existing encryption/key management tools (like LUKS)?
> Easy support in LVM? ...

DM extension gives us several capabilities:

1. Use the Linux keyring and other key management tools.

     - I used "keyctl padd user test-key @u < /tmp/wrapped_dek" at my tests

2. Split a single block device into several DMs. Allow us to use a 
different encryption key and encryption mode per DM.

3. Replace a key during I/O by using "dmsetup suspend /dev/dm-0" and 
"dmsetup  resume /dev/dm-0".

>
> Milan





More information about the dm-devel mailing list