From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Eric Biggers <ebiggers@kernel.org>
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: Tue, 16 May 2023 14:34:51 -0400 [thread overview]
Message-ID: <80496cfe-161d-fb0d-8230-93818b966b1b@dorminy.me> (raw)
In-Reply-To: <20230515064047.GC15871@sol.localdomain>
> To clarify my suggestion, blk-crypto could be used for file contents
> en/decryption at the same time that filesystem-layer crypto is used for verity
> metadata en/decryption. blk-crypto and filesystem-layer crypto don't need to be
> mutually exclusive, even on the same file.
That's a great point. I'm dropping these two patchsets and updating the
original one at the start of the year to use blk-crypto, as per our
discussions both here and at LSF.
>
> Also, I'm glad that you're interested in xattr encryption, but unfortunately
> it's a tough problem, and all the other filesystems that implement fscrypt have
> left it out. You have enough other things to worry about, so I think leaving
> xattr encryption out for now is the right call. Similarly, the other
> filesystems that implement fscrypt have left out encryption of inline data,
> instead opting to disable inline data on encrypted files.
A good point. I'll defer xattrs and inline data (and verity) for the
first round, and add in doing those with inode infos after getting
extent infos working well.
>
> Anyway, the main reason I'm sending this email is actually that I wanted to
> mention another possible solution to the per-extent key problem that I just
> became aware of. In v6.4-rc1, the crypto API added a new function
> crypto_clone_tfm() which allocates a new tfm object, given an existing one.
> Unlike crypto_alloc_tfm(), crypto_clone_tfm() doesn't take any locks. See:
> https://lore.kernel.org/linux-crypto/ZDefxOq6Ax0JeTRH@gondor.apana.org.au/T/#u
>
> For now, only shash and ahash tfms can be cloned. However, it looks like
> support for cloning skcipher tfms could be added.
>
> With "cloning" skcipher tfms, there could just be a crypto_skcipher per extent,
> allocated on the I/O path. That would solve the problem we've been trying to
> solve, without having to bring in the complexity of "pooled prepared keys".
Huh. A cool new thing for sure. I suppose one would have an initial tfm
per supported crypto alg, and clone it for each extent as needed. That's
definitely better than pooling prepared keys. I'll explore this after
everything else, and work on blk-crypto oriented for now.
Thanks!
Sweet Tea
prev parent reply other threads:[~2023-05-16 18:35 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
2023-05-06 0:35 ` Sweet Tea Dorminy
2023-05-15 6:40 ` Eric Biggers
2023-05-16 18:34 ` Sweet Tea Dorminy [this message]
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=80496cfe-161d-fb0d-8230-93818b966b1b@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).