linux-ext4 - [PATCH 0/5] fscrypt: add support for data_unit_size < fs_block

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 for Android: free password hash cracker in your pocket

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

Date:   Mon,  4 Sep 2023 17:58:25 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     linux-fscrypt@...r.kernel.org
Cc:     linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net, linux-btrfs@...r.kernel.org
Subject: [PATCH 0/5] fscrypt: add support for data_unit_size < fs_block_size

Until now, fscrypt has always used the filesystem block size as the
granularity of file contents encryption.  Two scenarios have come up
where a sub-block granularity of contents encryption would be useful:

1. Inline encryption hardware that only supports a crypto data unit size
   that is less than the filesystem block size.

2. Support for direct I/O at a granularity less than the filesystem
   block size, for example at the block device's logical block size in
   order to match the traditional direct I/O alignment requirement.

(1) first came up with older eMMC inline crypto hardware that only
supports a crypto data unit size of 512 bytes.  That specific case
ultimately went away because all systems with that hardware continued
using out of tree code and never actually upgraded to the upstream
inline crypto framework.  But, now it's coming back in a new way: some
current UFS controllers only support a data unit size of 4096 bytes, and
there is a proposal to increase the filesystem block size to 16K.

(2) was discussed as a "nice to have" feature, though not essential,
when support for direct I/O on encrypted files was being upstreamed.

Still, the fact that this feature has come up several times does suggest
it would be wise to have available.  Therefore, this patchset implements
it by using one of the reserved bytes in fscrypt_policy_v2 to allow
users to select a sub-block data unit size.  Supported values are powers
of 2 between 512 bytes and the filesystem block size, inclusively.

Patch 1-4 are preparatory patches.  Patch 5 is the actual feature.

Testing and userspace support are still in progress; there may be bugs
in this patchset.  I just wanted to get this out early in case anyone
has feedback on the feature itself and its likely implementation.

Note: this is unrelated to the work on extent based encryption that is
ongoing by the btrfs folks.  This is basically an orthogonal feature.

This patchset is based on mainline commit 708283abf896dd48

Eric Biggers (5):
  fscrypt: make it extra clear that key_prefix is deprecated
  fscrypt: make the bounce page pool opt-in instead of opt-out
  fscrypt: use s_maxbytes instead of filesystem lblk_bits
  fscrypt: replace get_ino_and_lblk_bits with just has_32bit_inodes
  fscrypt: support crypto data unit size less than filesystem block size

 Documentation/filesystems/fscrypt.rst | 115 ++++++++++++++------
 fs/crypto/bio.c                       |  39 ++++---
 fs/crypto/crypto.c                    | 148 +++++++++++++++-----------
 fs/crypto/fscrypt_private.h           |  51 +++++++--
 fs/crypto/inline_crypt.c              |  46 ++++++--
 fs/crypto/keysetup.c                  |  21 +++-
 fs/crypto/keysetup_v1.c               |   5 +-
 fs/crypto/policy.c                    |  69 +++++++-----
 fs/ext4/crypto.c                      |  13 +--
 fs/f2fs/super.c                       |  13 +--
 fs/ubifs/crypto.c                     |   3 +-
 include/linux/fscrypt.h               |  71 +++++++-----
 include/uapi/linux/fscrypt.h          |   3 +-
 13 files changed, 385 insertions(+), 212 deletions(-)

base-commit: 708283abf896dd4853e673cc8cba70acaf9bf4ea
-- 
2.42.0