On Wed, Jan 18, 2023 at 07:14:30AM +0000, Chaitanya Kulkarni wrote: > Eric, > > >> 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
