From: Eric Biggers <ebiggers@kernel.org>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-fscrypt@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v1 0/7] fscrypt: add pooled prepared keys facility
Date: Fri, 5 May 2023 22:40:13 +0000 [thread overview]
Message-ID: <ZFWFzUE6r30yVPB+@gmail.com> (raw)
In-Reply-To: <e7ee1491-e67c-6461-8825-6f39bf723c86@dorminy.me>
On Fri, May 05, 2023 at 08:15:44AM -0400, Sweet Tea Dorminy wrote:
>
> > As I mentioned earlier
> > (https://lore.kernel.org/r/Y7NQ1CvPyJiGRe00@sol.localdomain),
> > blk-crypto-fallback actually already solved the problem of caching
> > crypto_skcipher objects for I/O. And, it's possible for a filesystem to *only*
> > support blk-crypto, not filesystem-layer contents encryption. You'd just need
> > to put btrfs encryption behind a new kconfig option that is automatically
> > selected by CONFIG_FS_ENCRYPTION_INLINE_CRYPT && CONFIG_BLK_ENCRYPTION_FALLBACK.
> >
> > (BTW, I'm thinking of simplifying the kconfig options by removing
> > CONFIG_FS_ENCRYPTION_INLINE_CRYPT. Then, the blk-crypto code in fs/crypto/ will
> > be built if CONFIG_FS_ENCRYPTION && CONFIG_BLK_INLINE_ENCRYPTION.)
> >
> > Indeed, filesystem-layer contents encryption is a bit redundant these days now
> > that blk-crypto-fallback exists. I'm even tempted to make ext4 and f2fs support
> > blk-crypto only someday. That was sort of the original plan, actually...
> >
> > So, I'm wondering if you've considered going the blk-crypto-fallback route?
>
> I did, and gave it a shot, but ran into problems because as far as I can
> tell it requires having a bio to crypt. For verity data and inline extents,
> there's no obvious bio, and even if we tried to construct a bio pointing at
> the relevant data, it's not necessarily sector- sized or aligned. I couldn't
> figure out a good way to make it work, but maybe it's better to special-case
> those or there's something I'm not seeing.
ext4 and f2fs just don't use inline data on encrypted files. I.e. when an encrypted file is
created, it always uses non-inline data. Is that an option for btrfs?
For the verity metadata, how are you thinking of encrypting it, exactly? Verity metadata is
immutable once written, so surely it avoids many of the issues you are dealing with for extents? It
should just need one key, and that key could be set up at file open time. So I don't think it will
need the key pool at all?
- Eric
next prev parent reply other threads:[~2023-05-05 22:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 2:42 [PATCH v1 0/7] fscrypt: add pooled prepared keys facility Sweet Tea Dorminy
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 [this message]
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=ZFWFzUE6r30yVPB+@gmail.com \
--to=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-fscrypt@vger.kernel.org \
--cc=sweettea-kernel@dorminy.me \
--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 NNTP newsgroup(s).