[PATCH v1 0/7] fscrypt: add pooled prepared keys facility

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx


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




[Index of Archives]     [linux Cryptography]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]

  Powered by Linux