[dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt
Israel Rukshin
israelr at nvidia.com
Sun Jan 16 10:15:22 UTC 2022
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
More information about the dm-devel
mailing list