Re: RFC: what to do about fscrypt vs block device interaction

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Jul 22, 2022 at 06:24:45PM +0000, Eric Biggers wrote:
> On Fri, Jul 22, 2022 at 06:03:49PM +0200, Christoph Hellwig wrote:
> > > To avoid that, I think we could go through and evict all the
> > > blk_crypto_keys (i.e. call fscrypt_destroy_prepared_key() on the
> > > fscrypt_prepared_keys embedded in each fscrypt_master_key) during the
> > > unmount itself, separating it from the destruction of the key objects
> > > from the keyring subsystem's perspective. That could happen in the
> > > moved call to fscrypt_sb_free().
> 
> Note: for iterating through the keys in ->s_master_keys, I'd try something like
> assoc_array_iterate(&sb->s_master_keys->keys, fscrypt_teardown_key, sb)
> 
> > 
> > I'll give this a try.
> > 
> > What would be a good test suite or set of tests to make sure I don't
> > break fscrypt operation?
> 
> You can run xfstests on ext4 and f2fs with "-g encrypt", both with and without
> the inlinecrypt mount option.
> https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#tests shows the
> commands to do this with kvm-xfstests, but it can also be done with regular
> xfstests.  Note that for the inlinecrypt mount option to work you'll need a
> kernel with CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y and
> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y.
> 
> There are relevant things that aren't tested by this, such as f2fs's
> multi-device support and whether the blk-crypto keys really get evicted, but
> that's the best we have.

FYI, I'm working on a patchset that will address the issue with
blk_crypto_evict_key() that you were having trouble with here.  It turns out
there are some actual bugs caused by how fscrypt does things with
->s_master_keys, so I'm planning a larger cleanup that changes ->s_master_keys
to be a regular hash table instead, with lifetime rules adjusted accordingly.

- Eric