From: Eric Biggers <ebiggers@kernel.org> To: linux-fscrypt@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: [f2fs-dev] [PATCH 0/5] fscrypt: add support for data_unit_size < fs_block_size Date: Mon, 4 Sep 2023 17:58:25 -0700 [thread overview] Message-ID: <20230905005830.365985-1-ebiggers@kernel.org> (raw) 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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
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 Subject: [PATCH 0/5] fscrypt: add support for data_unit_size < fs_block_size Date: Mon, 4 Sep 2023 17:58:25 -0700 [thread overview] Message-ID: <20230905005830.365985-1-ebiggers@kernel.org> (raw) 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
next reply other threads:[~2023-09-05 1:04 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-09-05 0:58 Eric Biggers [this message] 2023-09-05 0:58 ` [PATCH 0/5] fscrypt: add support for data_unit_size < fs_block_size Eric Biggers 2023-09-05 0:58 ` [f2fs-dev] [PATCH 1/5] fscrypt: make it extra clear that key_prefix is deprecated Eric Biggers 2023-09-05 0:58 ` Eric Biggers 2023-09-05 0:58 ` [f2fs-dev] [PATCH 2/5] fscrypt: make the bounce page pool opt-in instead of opt-out Eric Biggers 2023-09-05 0:58 ` Eric Biggers 2023-09-05 0:58 ` [f2fs-dev] [PATCH 3/5] fscrypt: use s_maxbytes instead of filesystem lblk_bits Eric Biggers 2023-09-05 0:58 ` Eric Biggers 2023-09-05 0:58 ` [f2fs-dev] [PATCH 4/5] fscrypt: replace get_ino_and_lblk_bits with just has_32bit_inodes Eric Biggers 2023-09-05 0:58 ` Eric Biggers 2023-09-05 0:58 ` [f2fs-dev] [PATCH 5/5] fscrypt: support crypto data unit size less than filesystem block size Eric Biggers 2023-09-05 0:58 ` 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=20230905005830.365985-1-ebiggers@kernel.org \ --to=ebiggers@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 \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.