linux-kernel - [PATCH RFC 0/4] fscrypt changes for btrfs encryption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 23 Jul 2022 20:52:24 -0400
From:   Sweet Tea Dorminy <sweettea-kernel@...miny.me>
To:     "Theodore Y . Ts'o " <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Eric Biggers <ebiggers@...nel.org>,
        linux-fscrypt@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-btrfs@...r.kernel.org, osandov@...ndov.com,
        kernel-team@...com
Cc:     Sweet Tea Dorminy <sweettea-kernel@...miny.me>
Subject: [PATCH RFC 0/4] fscrypt changes for btrfs encryption

This is the fscrypt section of my draft patch series [1] to add
encryption support to btrfs.

Last October, Omar Sandoval sent out a design proposal for using fscrypt
with btrfs [2]. To tersely summarize the challenges laid out in the
document, btrfs supports sharing the same physical storage between
multiple files (reflinks); moving the physical location of file data
without access to the file inodes; and creating writable snapshots of
some directories (subvolumes). To allow encryption to coexist with these
features, the proposal was for btrfs to create and preserve an IV per
data block, no matter its physical location or owning inode(s), and for
btrfs to allow partially-encrypted writable snapshots of unencrypted
subvolumes.

To deal with these issues, a few changes to fscrypt are proposed:
- To enable snapshotting and then encrypting new writes to that
  subvolume, a flag to allow partially encrypted directories;
- To allow filesystems to supply an IV in cases where the logical block
  number and owning inode for data may change, a new policy and
  interface to convey IVs from filesystem to fscrypt.

Comments, especially on the new policy and interface, appreciated!

[1] https://lore.kernel.org/linux-btrfs/cover.1658623319.git.sweettea-kernel@dorminy.me
[2] https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@relinquished.localdomain/

Omar Sandoval (3):
  fscrypt: expose fscrypt_nokey_name
  fscrypt: add flag allowing partially-encrypted directories
  fscrypt: add fscrypt_have_same_policy() to check inode's compatibility

Sweet Tea Dorminy (1):
  fscrypt: Add new encryption policy for btrfs.

 fs/crypto/crypto.c           | 28 +++++++++++++++--
 fs/crypto/fname.c            | 56 ++++++++++-----------------------
 fs/crypto/fscrypt_private.h  |  4 +--
 fs/crypto/inline_crypt.c     | 20 ++++++++----
 fs/crypto/keysetup.c         |  5 +++
 fs/crypto/policy.c           | 42 ++++++++++++++++++++++++-
 include/linux/fscrypt.h      | 61 +++++++++++++++++++++++++++++++++++-
 include/uapi/linux/fscrypt.h |  1 +
 8 files changed, 166 insertions(+), 51 deletions(-)

-- 
2.35.1