Re: [PATCH v2 10/11] fscrypt: explicitly track prepared parts of key

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Apr 11, 2023 at 12:45:28PM -0400, Sweet Tea Dorminy wrote:
> You're noting that we only really need preparedness for per-mode keys, and
> that's a point I didn't explicitly grasp before; everywhere else we know
> whether it's merely allocated or fully prepared. Two other thoughts on ways
> we could pull the preparedness out of fscrypt_prepared_key and still keep
> locklessness:
> 
> fscrypt_master_key could setup both block key and tfm (if block key is
> applicable) when it sets up a prepared key, so we can use just one bit of
> preparedness information, and keep a bitmap recording which prepared keys
> are ready in fscrypt_master_key.
> 
> Or we could have
> struct fscrypt_master_key_prepared_key {
> 	u8 preparedness;
> 	struct fscrypt_prepared_key prep_key;
> }
> and similarly isolate the preparedness tracking from per-file keys.
> 
> Do either of those sound appealing as alternatives to the semaphore?

Not really.  The bitmaps add extra complexity.  Also note that the tfm and
blk-crypto key do need to be considered separately, as there can be cases where
blk-crypto supports the algorithm but the crypto API doesn't, and vice versa.

I think that for the per-mode keys, we should either keep the current behavior
where prep_key->tfm and prep_key->blk_key aren't set until they're fully ready
(in which case the lockless check continues to be fairly straightforward), *or*
we should make it no longer lockless.

- Eric