[v2,00/11] fscrypt: rearrangements preliminary to extent encryption

Message

Sweet Tea Dorminy April 10, 2023, 7:39 p.m. UTC

As per [1], extent-based encryption needs to split allocating and
preparing crypto_skciphers, since extent infos will be loaded at IO time
and crypto_skciphers cannot be allocated at IO time. 

This changeset undertakes to split the existing code to clearly
distinguish preparation and allocation of fscrypt_prepared_keys,
wrapping crypto_skciphers. Elegance of code is in the eye of the
beholder, but I've tried a decent variety of arrangements here and this
seems like the clearest result to me; happy to adjust as desired, and
more changesets coming soon, this just seemed like the clearest cutoff
point for preliminaries without being pure refactoring.

Patchset should apply cleanly to fscrypt/for-next (as per base-commit
below), and pass ext4/f2fs tests (kvm-xfstests is not currently
succesfully setting up ubifs volumes for me).

[1] https://lore.kernel.org/linux-btrfs/[e-mail]/ 

Changes from v1:
Included change 1, erroneously dropped, and generated patches using --base.

Sweet Tea Dorminy (11):
  fscrypt: move inline crypt decision to info setup.
  fscrypt: split and rename setup_file_encryption_key()
  fscrypt: split and rename setup_per_mode_enc_key()
  fscrypt: move dirhash key setup away from IO key setup
  fscrypt: reduce special-casing of IV_INO_LBLK_32
  fscrypt: make infos have a pointer to prepared keys
  fscrypt: move all the shared mode key setup deeper
  fscrypt: make ci->ci_direct_key a bool not a pointer
  fscrypt: make prepared keys record their type.
  fscrypt: explicitly track prepared parts of key
  fscrypt: split key alloc and preparation

 fs/crypto/crypto.c          |   2 +-
 fs/crypto/fname.c           |   4 +-
 fs/crypto/fscrypt_private.h |  73 +++++--
 fs/crypto/inline_crypt.c    |  30 +--
 fs/crypto/keysetup.c        | 387 ++++++++++++++++++++++++------------
 fs/crypto/keysetup_v1.c     |  13 +-
 6 files changed, 340 insertions(+), 169 deletions(-)


base-commit: 83e57e47906ce0e99bd61c70fae514e69960d274

Comments

Eric Biggers April 11, 2023, 3:18 a.m. UTC | #1

Hi Sweet Tea,

On Mon, Apr 10, 2023 at 03:39:53PM -0400, Sweet Tea Dorminy wrote:
> As per [1], extent-based encryption needs to split allocating and
> preparing crypto_skciphers, since extent infos will be loaded at IO time
> and crypto_skciphers cannot be allocated at IO time. 
> 
> This changeset undertakes to split the existing code to clearly
> distinguish preparation and allocation of fscrypt_prepared_keys,
> wrapping crypto_skciphers. Elegance of code is in the eye of the
> beholder, but I've tried a decent variety of arrangements here and this
> seems like the clearest result to me; happy to adjust as desired, and
> more changesets coming soon, this just seemed like the clearest cutoff
> point for preliminaries without being pure refactoring.
> 
> Patchset should apply cleanly to fscrypt/for-next (as per base-commit
> below), and pass ext4/f2fs tests (kvm-xfstests is not currently
> succesfully setting up ubifs volumes for me).
> 
> [1] https://lore.kernel.org/linux-btrfs/[e-mail]/ 
> 
> Changes from v1:
> Included change 1, erroneously dropped, and generated patches using --base.
> 
> Sweet Tea Dorminy (11):
>   fscrypt: move inline crypt decision to info setup.
>   fscrypt: split and rename setup_file_encryption_key()
>   fscrypt: split and rename setup_per_mode_enc_key()
>   fscrypt: move dirhash key setup away from IO key setup
>   fscrypt: reduce special-casing of IV_INO_LBLK_32
>   fscrypt: make infos have a pointer to prepared keys
>   fscrypt: move all the shared mode key setup deeper
>   fscrypt: make ci->ci_direct_key a bool not a pointer
>   fscrypt: make prepared keys record their type.
>   fscrypt: explicitly track prepared parts of key
>   fscrypt: split key alloc and preparation
> 
>  fs/crypto/crypto.c          |   2 +-
>  fs/crypto/fname.c           |   4 +-
>  fs/crypto/fscrypt_private.h |  73 +++++--
>  fs/crypto/inline_crypt.c    |  30 +--
>  fs/crypto/keysetup.c        | 387 ++++++++++++++++++++++++------------
>  fs/crypto/keysetup_v1.c     |  13 +-
>  6 files changed, 340 insertions(+), 169 deletions(-)
> 

Thanks for the patchset!  I don't see any major issues with these cleanups; I'll
leave some comments on individual patches.  But, I also feel that most of them
aren't too convincing on their own.  So, I'm very interested in seeing where you
go with this.  It seems that your goal is to allow filesystems to more directly
create and manage fscrypt_prepared_key structs.  Do you know when you'll have a
proof of concept ready that includes the changes/additions to the interface
between fs/crypto/ and filesystems (include/linux/fscrypt.h)?

- Eric