On Thu, Jan 27, 2022 at 06:08:40AM -0500, Jeff Layton wrote: > On Wed, 2022-01-26 at 18:14 -0800, Eric Biggers wrote: > > On Tue, Jan 11, 2022 at 02:15:20PM -0500, Jeff Layton wrote: > > > Still, I was able to run xfstests on this set yesterday. Bug #2 above > > > prevented all of the tests from passing, but it didn't oops! I call that > > > progress! Given that, I figured this is a good time to post what I have > > > so far. > > > > One question: what sort of testing are you doing to show that the file contents > > and filenames being stored (i.e., sent by the client to the server in this case) > > have been encrypted correctly? xfstests has tests that verify this for block > > device based filesystems; are you doing any equivalent testing? > > > > I've been testing this pretty regularly with xfstests, and the filenames > portion all seems to be working correctly. Parts of the content > encryption also seem to work ok. I'm still working that piece, so I > haven't been able to validate that part yet. > > At the moment I'm working on switching the ceph client over to doing > sparse reads, which is necessary in order to be able to handle sparse > writes without filling in unwritten holes. To clarify, I'm asking about the correctness of the ciphertext written to "disk", not about the user-visible filesystem behavior which is something different (but also super important as well, of course). xfstests includes both types of tests. Grepping for _verify_ciphertext_for_encryption_policy in xfstests will show the tests that verify the ciphertext written to disk. I doubt that you're running those, as they rely on a block device. So you'll need to write some equivalent tests. In a pinch, you could simply check that the ciphertext is random rather than correct (that would at least show that it's not plaintext) like what generic/399 does. But actually verifying its correctness would be ideal to ensure that nothing went wrong along the way. - Eric
