On Wed, Jan 18, 2023 at 07:14:30AM +0000, Chaitanya Kulkarni wrote:

Eric,

quoted

quoted

Notes:
  - At plaintext mode only, the user set a master key and the fscrypt
    driver derived from it the DEK and the key identifier.
  - 152c41b2ea39fa3d90ea06448456e7fb is the derived key identifier
  - Only on the first IO, nvme-rdma gets a callback to load the derived DEK.

There is no special configuration to support crypto at nvme modules.

Thanks

Very interesting work!  Can you Cc me on future versions?

I'm glad to see that this hardware allows all 16 IV bytes to be specified.

Does it also handle programming and evicting keys efficiently?

Also, just checking: have you tested that the ciphertext that this inline
encryption hardware produces is correct?  That's always super important to test.
There are xfstests that test for it, e.g. generic/582.  Another way to test it
is to just manually test whether encrypted files that were created when the
filesystem was mounted with '-o inlinecrypt' show the same contents when the
filesystem is *not* mounted with '-o inlinecrypt' (or vice versa).

- Eric

I'm wondering which are the xfstests that needs to run in order
to establish the correctness/stability apart from generic/582
this work ?

See https://docs.kernel.org/filesystems/fscrypt.html#tests.

- Eric