[RFC PATCH 0/4] fscrypt: add support for per-extent encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

This is meant as a replacement for the last set of patches Sweet Tea sent [1].
This is an attempt to find a different path forward.  Strip down everything to
the basics.  Essentially all we appear to need is a nonce, and then we can use
the inode context to derive per-extent keys.

I'm sending this as an RFC to see if this is a better direction to try and make
some headway on this project.  The btrfs side doesn't change too much, the code
just needs to be adjusted to use the new helpers for the extent contexts.  I
have this work mostly complete, but I'm afraid I won't have it ready for another
day or two and I want to get feedback on this ASAP before I burn too much time
on it.

Additionally there is a callback I've put in the inline block crypto stuff that
we need in order to handle the checksumming.  I made my best guess here as to
what would be the easiest and simplest way to acheive what we need, but I'm open
to suggestions here.

The other note is I've disabled all of the policy variations other than default
v2 policies if you enable extent encryption.  This is for simplicity sake.  We
could probably make most of it work, but reflink is basically impossible for v1
with direct key, and is problematic for the lblk related options.  It appears
this is fine, as those other modes are for specific use cases and the vast
majority of normal users are encouraged to use normal v2 policies anyway.

This stripped down version gives us most of what we want, we can reflink between
different inodes that have the same policy.  We lose the ability to mix
differently encrypted extents in the same inode, but this is an acceptable
limitation for now.

This has only been compile tested, and as I've said I haven't wired it
completely up into btrfs yet.  But this is based on a rough wire up and appears
to give us everything we need.  The btrfs portion of Sweet Teas patches are
basically untouched except where we use these helpers to deal with the extent
contexts.  Thanks,

Josef

[1] https://lore.kernel.org/linux-fscrypt/cover.1693630890.git.sweettea-kernel@xxxxxxxxxx/

Josef Bacik (4):
  fscrypt: rename fscrypt_info => fscrypt_inode_info
  fscrypt: add per-extent encryption support
  fscrypt: disable all but standard v2 policies for extent encryption
  blk-crypto: add a process bio callback

 block/blk-crypto-fallback.c |  18 ++++
 block/blk-crypto-profile.c  |   2 +
 block/blk-crypto.c          |   6 +-
 fs/crypto/crypto.c          |  23 +++--
 fs/crypto/fname.c           |   6 +-
 fs/crypto/fscrypt_private.h |  78 ++++++++++++----
 fs/crypto/hooks.c           |   2 +-
 fs/crypto/inline_crypt.c    |  50 +++++++++--
 fs/crypto/keyring.c         |   4 +-
 fs/crypto/keysetup.c        | 174 ++++++++++++++++++++++++++++++++----
 fs/crypto/keysetup_v1.c     |  14 +--
 fs/crypto/policy.c          |  45 ++++++++--
 include/linux/blk-crypto.h  |   9 +-
 include/linux/fs.h          |   4 +-
 include/linux/fscrypt.h     |  41 ++++++++-
 15 files changed, 400 insertions(+), 76 deletions(-)

-- 
2.41.0




[Index of Archives]     [linux Cryptography]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]

  Powered by Linux