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
|