From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Eric Biggers <ebiggers@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-fscrypt@vger.kernel.org, kernel-team@meta.com
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: [PATCH v1 0/7] fscrypt: add pooled prepared keys facility
Date: Tue, 18 Apr 2023 22:42:09 -0400 [thread overview]
Message-ID: <cover.1681871298.git.sweettea-kernel@dorminy.me> (raw)
This is part two of two of preliminaries to extent-based encryption,
adding a facility to pool pre-allocated prepared keys and use them at IO
time.
While arguably one structure within the feature, and not actually used
in this changeset at that, it's a disjoint piece that has various taste
questions so I've put it in its own changeset here for good or ill.
The change has been tested by switching a false to true so as to use it
for leaf inodes which are doing contents encryption, and then running
the standard tests. Such a thing changes the timing of when the prepared
key is set up, obviously, so that IO which begins after a master key
secret is removed no longer succeeds; this fails generic/{580,581,593}
which don't have that expectation. However, this code has no impact on
tests if disabled.
Known suboptimalities:
-right now at the end nothing calls fscrypt_shrink_key_pool() and it
throws an unused function warning.
-right now it's hooked up to be used by leaf inodes not using inline
encryption only. I don't know if there's any interest in pooling inode
keys -- it could reduce memory usage on memory-constrained platforms --
and if so using it for filename encryption also might make sense. On the
other hand, if there's no interest, the code allowing use of it in the normal
inode-info path is unnecessary.
-right now it doesn't pool inline encryption objects either.
-the initialization of a key pool for each mode spams the log with
"Missing crypto API support" messages. Maybe the init of key pools
should be the first time an info using pooled prepared keys is observed?
Some questions:
-does the pooling mechanism need to be extended to mode keys, which can
easily be pre-allocated if needed?
-does it need to be extended to v1 policies?
-does it need to be behind a config option, perhaps with extent
encryption?
-should it be in its own, new file, since it adds a decent chunk of code
to keysetup.c most of which is arguably key-agnostic?
This changeset should apply atop the previous one, entitled
'fscrypt: rearrangements preliminary to extent encryption'
lore.kernel.org/r/cover.1681837335.git.sweettea-kernel@dorminy.me
Sweet Tea Dorminy (7):
fscrypt: add new pooled prepared keys.
fscrypt: set up pooled keys upon first use
fscrypt: add pooling of pooled prepared keys.
fscrypt: add pooled prepared key locking around use
fscrypt: reclaim pooled prepared keys under pressure
fscrypt: add facility to shrink a pool of keys
fscrypt: add lru mechanism to choose pooled key
fs/crypto/crypto.c | 28 ++-
fs/crypto/fscrypt_private.h | 37 +++
fs/crypto/keyring.c | 7 +
fs/crypto/keysetup.c | 440 +++++++++++++++++++++++++++++++++---
4 files changed, 468 insertions(+), 44 deletions(-)
--
2.40.0
next reply other threads:[~2023-04-19 2:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 2:42 Sweet Tea Dorminy [this message]
2023-04-19 2:42 ` [PATCH v1 1/7] fscrypt: add new pooled prepared keys Sweet Tea Dorminy
2023-04-19 2:42 ` [PATCH v1 2/7] fscrypt: set up pooled keys upon first use Sweet Tea Dorminy
2023-04-19 2:42 ` [PATCH v1 3/7] fscrypt: add pooling of pooled prepared keys Sweet Tea Dorminy
2023-04-19 2:42 ` [PATCH v1 4/7] fscrypt: add pooled prepared key locking around use Sweet Tea Dorminy
2023-04-19 2:42 ` [PATCH v1 5/7] fscrypt: reclaim pooled prepared keys under pressure Sweet Tea Dorminy
2023-04-19 2:42 ` [PATCH v1 6/7] fscrypt: add facility to shrink a pool of keys Sweet Tea Dorminy
2023-04-19 2:42 ` [PATCH v1 7/7] fscrypt: add lru mechanism to choose pooled key Sweet Tea Dorminy
2023-05-02 3:47 ` [PATCH v1 0/7] fscrypt: add pooled prepared keys facility Eric Biggers
2023-05-05 12:15 ` Sweet Tea Dorminy
2023-05-05 22:40 ` Eric Biggers
2023-05-06 0:35 ` Sweet Tea Dorminy
2023-05-15 6:40 ` Eric Biggers
2023-05-16 18:34 ` Sweet Tea Dorminy
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=cover.1681871298.git.sweettea-kernel@dorminy.me \
--to=sweettea-kernel@dorminy.me \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-fscrypt@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).