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

[Israel Rukshin <israelr@nvidia.com>]

Hi Eric,

On 1/15/2022 12:49 AM, Eric Biggers wrote:
> Hi Israel,
>
> On Thu, Jan 13, 2022 at 08:09:00PM +0200, Israel Rukshin wrote:
>> Hi,
>>
>> I am working to add support for inline encryption/decryption
>> at storage protocols like nvmf over RDMA. The HW that I am
>> working with is ConnecX-6 Dx, which supports inline crypto
>> and can send the data on the fabric at the same time.
>>
>> This patchset is based on v5.16-rc4 with Eric Biggers patches
>> of the HW wrapped keys.
>> It can be retrieved from branch "wip-wrapped-keys" at
>> https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git
>>
>> I tested this patch with modified nvme-rdma as the block device
>> and created a DM crypt on top of it. I got performance enhancement
>> compared to SW crypto. I tested the HW wrapped inline mode with
>> the HW and the standard mode with a fallback algorithm.
>>
>> Israel Rukshin (1):
>>    dm crypt: Add inline encryption support
>>
>>   block/blk-crypto.c    |   3 +
>>   drivers/md/dm-crypt.c | 202 ++++++++++++++++++++++++++++++++++++------
>>   2 files changed, 180 insertions(+), 25 deletions(-)
> I appreciate the interest in my patchset that adds support for hardware-wrapped
> inline encryption keys
> (https://lore.kernel.org/linux-block/20211116033240.39001-1-ebiggers@kernel.org).
> So far I've received very little feedback on it.
>
> One of the challenges I've been having is that I still have no platform on which
> I can actually test hardware-wrapped keys with the upstream kernel.  The feature
> cannot be accepted upstream until there is a way to test it.  It's almost
> working on the SM8350 SoC, but I am waiting for Qualcomm to fix some things.
>
> It sounds like you've implemented a block device driver that exposes support for
> hardware-wrapped keys.  Can you please post that driver?

Yes, I implemented your inline callbacks at nvme-rdma driver. The driver 
communicates with

the HW via a general ib_verbs layer, so I had to extend ib_verbs and 
mlx5_ib drivers. Those

patches are at internal review and I will send the nvme-rdma patches 
afterwards.

>
> Can you also elaborate on how wrapped keys work in your case?  In particular,
> are they compatible with the whole design which I've documented in detail in my
> patchset?  That would include implementing the ->import_key, ->generate_key,
> ->prepare_key, and ->derive_sw_secret operations.  All the different parts are
> important.  If something needs to be optional, that's something I can consider
> incorporating into the design, but it would restrict the use cases.

In my case, the user should create wrapped keys by himself via a user 
space  tool based

on openssl library. Therefore, the ->import_key, ->generate_key and 
->prepare_key are

not necessary at my case. Regarding ->derive_sw_secret, it is not 
supported right now by

ConnectX6 DX firmware (we plan to add support for this).  To test 
fscrypt with wrapped keys,

a temporary WA was added to the ->derive_sw_secret at nvme-rdma driver. 
The other callbacks

you mentioned were left empty.

>
> Also, will your driver only support wrapped keys, or will it support standard
> keys too?

Our driver will support both modes. The first step is to support the 
standard keys, because of

the gap I mentioned above. As I understand, ->derive_sw_secret is not 
needed for dm-crypt.

Is that right?

>
> - Eric


--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel