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?) * 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? > > 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. 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
