From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-btrfs@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: [PATCH v3 0/5] fscrypt: add support for data_unit_size < fs_block_size
Date: Sun, 24 Sep 2023 22:54:46 -0700 [thread overview]
Message-ID: <20230925055451.59499-1-ebiggers@kernel.org> (raw)
This patchset adds support for configuring the granularity of file
contents encryption (a.k.a. the "crypto data unit size") to be less than
the filesystem block size on ext4 and f2fs. The main use case for this
is to support inline crypto hardware that only supports a data unit size
that is less than the FS block size being used. Another possible use
case is to support direct I/O on encrypted files without the FS block
alignment restriction. Note that decreasing the crypto data unit size
decreases efficiency, so this feature should only be used when needed.
For full details, see patch 5 which adds the actual feature. Patches
1-4 are preparatory patches.
I've written an xfstest that verifies that when a sub-block data unit
size is selected, the data on-disk is encrypted correctly with that data
unit size. I'll be sending that out separately. Other testing of this
patchset with xfstests has gone well, though it turns out that some
additional changes will be needed for a sub-block data unit size to work
with the IV_INO_LBLK_* encryption settings. See patch 5 for details.
This patchset focuses on basic sub-block data unit size support first.
This patchset will cause some conflicts in the extent-based encryption
patches that the btrfs folks are working on, as both are touching file
contents encryption, but logically they are orthogonal features.
This patchset is based on v6.6-rc3.
Changed in v3:
- Shortened 'legacy_key_prefix_for_backcompat' to 'legacy_key_prefix'
- Other miscellaneous cleanups
- Rebased onto v6.6-rc3
Changed in v2:
- Rebased onto v6.6-rc1 and took into account CephFS's recent addition
of support for fscrypt
- Narrowed the focus somewhat by dropping the attempted support for
IV_INO_LBLK_32 and clearly documenting what is considered out of
scope for now
- Other cleanups
Eric Biggers (5):
fscrypt: make it clearer that key_prefix is deprecated
fscrypt: make the bounce page pool opt-in instead of opt-out
fscrypt: compute max_lblk_bits from s_maxbytes and block size
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 | 117 ++++++++++++++------
fs/ceph/crypto.c | 1 +
fs/crypto/bio.c | 39 ++++---
fs/crypto/crypto.c | 148 +++++++++++++++-----------
fs/crypto/fscrypt_private.h | 58 ++++++++--
fs/crypto/inline_crypt.c | 19 ++--
fs/crypto/keysetup.c | 5 +
fs/crypto/keysetup_v1.c | 5 +-
fs/crypto/policy.c | 73 +++++++++----
fs/ext4/crypto.c | 13 +--
fs/f2fs/super.c | 13 +--
fs/ubifs/crypto.c | 3 +-
include/linux/fscrypt.h | 72 ++++++++-----
include/uapi/linux/fscrypt.h | 3 +-
14 files changed, 364 insertions(+), 205 deletions(-)
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
--
2.42.0
next reply other threads:[~2023-09-25 5:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 5:54 Eric Biggers [this message]
2023-09-25 5:54 ` [PATCH v3 1/5] fscrypt: make it clearer that key_prefix is deprecated Eric Biggers
2023-09-25 5:54 ` [PATCH v3 2/5] fscrypt: make the bounce page pool opt-in instead of opt-out Eric Biggers
2023-09-25 5:54 ` [PATCH v3 3/5] fscrypt: compute max_lblk_bits from s_maxbytes and block size Eric Biggers
2023-09-25 5:54 ` [PATCH v3 4/5] fscrypt: replace get_ino_and_lblk_bits with just has_32bit_inodes Eric Biggers
2023-09-25 5:54 ` [PATCH v3 5/5] fscrypt: support crypto data unit size less than filesystem block size Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230925055451.59499-1-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox