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
BLKCRYPTOCREATEKEY and BLKCRYPTOPREPAREKEY. (Could you elaborate on
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 https://lore.kernel.org/r/20211208013534.136590-1-ebiggers@xxxxxxxxxx, 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
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
