All of
 help / color / mirror / Atom feed
From: Israel Rukshin <>
To: Eric Biggers <>
Cc: Max Gurtovoy <>,
	dm-devel <>, Nitzan Carmi <>,
Subject: Re: [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt
Date: Wed, 19 Jan 2022 17:45:04 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Yecc1BemVbBSjEo+@sol.localdomain>

On 1/18/2022 10:02 PM, Eric Biggers wrote:
> On Sun, Jan 16, 2022 at 12:15:22PM +0200, Israel Rukshin wrote:
>> 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.
> So, what we need to think about is how userspace is expected to actually use and
> test the hardware-wrapped keys feature.
> My patchset proposed a design where if a block device declares support for
> hardware-wrapped keys, then the BLKCRYPTOCREATEKEY and BLKCRYPTOPREPAREKEY
> ioctls are available.
> Additionally, a specific hardware-internal key hierarchy and KDF is assumed (due
> to the need to support ->derive_sw_secret).  While userspace doesn't need to
> know these details to use the feature normally, they *must* be known in order to
> test that it's actually working correctly.
> If we were to support variants of the feature, such as:
> * Hardware-wrapped keys must be created/prepared in some way other than
>    what this way actually is, in your case?)

We currently assume that the same entity that configured the device the first time
and pushed the first wrapping key to it is able to produce DEKs (Data Encryption keys)
which are passed to the software in a wrapped form, to be loaded to that particular
device as-is.
At our case, we produce the wrapped DEKs at a different machine which may be placed
at a more secured environment.

> * Hardware's key hierarchy or KDF is different, so userspace must do something
>    else when verifying the on-disk ciphertext.
> ... then we would need to precisely specify these other variants, and define a
> way for userspace to discover what it should do.
> In, I'm
> proposing exposing the crypto capabilities of block devices via sysfs.  That
> could lead to a partial solution, e.g. the kernel could provide a file
> 	/sys/block/$disk/queue/crypto/wrapped_keys_variant
> ... which would allow userspace to discover the supported variant of
> hardware-wrapped keys.  I was really hoping that one variant could be
> standardized, but that is one possibility.
>>> 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
> Okay, great.  If you're adding inline encryption support to dm-crypt (or to
> dm-inline-crypt or to the block layer, depending on what people decide is the
> best approach), perhaps you should start with standard keys only, to avoid a
> dependency on the hardware-wrapped keys feature which is still being worked on?
Yes, I will do it.
>> the gap I mentioned above. As I understand, ->derive_sw_secret is not needed
>> for dm-crypt.
>> Is that right?
> That's correct.  The larger issue is that if you don't support
> ->derive_sw_secret, then it's likely that your key hierarchy is different
> (probably you don't have a "hierarchy", but rather just one key), which would
> imply that the feature needs to be tested differently.
We plan to support also ->derive_sw_secret.
> As per the above, this could be accounted for in the design by allowing multiple
> variants of wrapped keys.  Of course, that would add complexity.
> - Eric

dm-devel mailing list

      reply	other threads:[~2022-01-19 15:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13 18:09 [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt Israel Rukshin
2022-01-13 18:09 ` [dm-devel] [PATCH 1/1] dm crypt: Add inline encryption support Israel Rukshin
2022-01-14  8:06   ` Damien Le Moal
2022-01-14  8:14   ` Damien Le Moal
2022-01-16 10:29     ` Israel Rukshin
2022-01-13 21:22 ` [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt Bart Van Assche
2022-01-14 20:51 ` Milan Broz
2022-01-14 22:27   ` Eric Biggers
2022-01-15  9:22     ` Milan Broz
2022-01-18 19:38       ` Eric Biggers
2022-01-19  5:18         ` Christoph Hellwig
2022-01-17  7:52   ` Christoph Hellwig
2022-01-17 10:50     ` Milan Broz
2022-01-17 14:00       ` Israel Rukshin
2022-01-18 16:45         ` Christoph Hellwig
2022-01-18 20:27           ` Eric Biggers
2022-01-19  5:15             ` Christoph Hellwig
2022-01-14 22:49 ` Eric Biggers
2022-01-16 10:15   ` Israel Rukshin
2022-01-18 20:02     ` Eric Biggers
2022-01-19 15:45       ` Israel Rukshin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.