From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Satya Tangirala <satyat@google.com>,
Paul Crowley <paulcrowley@google.com>,
Paul Lawrence <paullawrence@google.com>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies
Date: Tue, 5 Nov 2019 20:05:19 -0800 [thread overview]
Message-ID: <20191106040519.GA705@sol.localdomain> (raw)
In-Reply-To: <20191106033544.GG26959@mit.edu>
On Tue, Nov 05, 2019 at 10:35:44PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Oct 24, 2019 at 02:54:36PM -0700, Eric Biggers wrote:
> > @@ -83,6 +118,10 @@ bool fscrypt_supported_policy(const union fscrypt_policy *policy_u,
> > return false;
> > }
> >
> > + if ((policy->flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) &&
> > + !supported_iv_ino_lblk_64_policy(policy, inode))
> > + return false;
> > +
> > if (memchr_inv(policy->__reserved, 0,
> > sizeof(policy->__reserved))) {
> > fscrypt_warn(inode,
>
> fscrypt_supported_policy is getting more and more complicated, and
> supported_iv_ino_lblk_64_policy calls a fs-supplied callback function,
> etc. And we need to use this every single time we need to set up an
> inode. Granted that compared to the crypto, even if it is ICE, it's
> probably small beer --- but perhaps we should think about caching some
> of what fscrypt_supported_policy does on a per-file system basis at
> some point?
I don't think this will make any difference given everything else that needs to
be done to set up a file's key. Also, anything extra we spend here will be far
less than the amount of time we save with IV_INO_LBLK_64 policies by not having
to do the key derivation and tfm allocation for every file.
Christoph suggested replacing ->has_stable_inodes() and
->get_ino_and_lblk_bits() with a new SB_* flag like SB_IV_INO_LBLK_64_SUPPORT.
But I don't like that that would result in worse error messages and would "leak"
a specific fscrypt policy flag into filesystems rather than having the
filesystems declare their properties.
If we really wanted to optimize fscrypt_get_encryption_info(), I think we
probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather
take advantage of the fact that fscrypt_has_permitted_context() already ran.
E.g., we could cache the xattr, or skip both the keyring lookup and
fscrypt_supported_policy() by grabbing them from the parent directory.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-f2fs-devel@lists.sourceforge.net,
Satya Tangirala <satyat@google.com>,
Paul Lawrence <paullawrence@google.com>,
linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [f2fs-dev] [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies
Date: Tue, 5 Nov 2019 20:05:19 -0800 [thread overview]
Message-ID: <20191106040519.GA705@sol.localdomain> (raw)
In-Reply-To: <20191106033544.GG26959@mit.edu>
On Tue, Nov 05, 2019 at 10:35:44PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Oct 24, 2019 at 02:54:36PM -0700, Eric Biggers wrote:
> > @@ -83,6 +118,10 @@ bool fscrypt_supported_policy(const union fscrypt_policy *policy_u,
> > return false;
> > }
> >
> > + if ((policy->flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) &&
> > + !supported_iv_ino_lblk_64_policy(policy, inode))
> > + return false;
> > +
> > if (memchr_inv(policy->__reserved, 0,
> > sizeof(policy->__reserved))) {
> > fscrypt_warn(inode,
>
> fscrypt_supported_policy is getting more and more complicated, and
> supported_iv_ino_lblk_64_policy calls a fs-supplied callback function,
> etc. And we need to use this every single time we need to set up an
> inode. Granted that compared to the crypto, even if it is ICE, it's
> probably small beer --- but perhaps we should think about caching some
> of what fscrypt_supported_policy does on a per-file system basis at
> some point?
I don't think this will make any difference given everything else that needs to
be done to set up a file's key. Also, anything extra we spend here will be far
less than the amount of time we save with IV_INO_LBLK_64 policies by not having
to do the key derivation and tfm allocation for every file.
Christoph suggested replacing ->has_stable_inodes() and
->get_ino_and_lblk_bits() with a new SB_* flag like SB_IV_INO_LBLK_64_SUPPORT.
But I don't like that that would result in worse error messages and would "leak"
a specific fscrypt policy flag into filesystems rather than having the
filesystems declare their properties.
If we really wanted to optimize fscrypt_get_encryption_info(), I think we
probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather
take advantage of the fact that fscrypt_has_permitted_context() already ran.
E.g., we could cache the xattr, or skip both the keyring lookup and
fscrypt_supported_policy() by grabbing them from the parent directory.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-11-06 4:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers
2019-10-24 21:54 ` [f2fs-dev] " Eric Biggers
2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers
2019-10-24 21:54 ` [f2fs-dev] " Eric Biggers
2019-10-29 17:47 ` Paul Crowley
2019-10-29 17:47 ` [f2fs-dev] " Paul Crowley via Linux-f2fs-devel
2019-11-06 3:35 ` Theodore Y. Ts'o
2019-11-06 3:35 ` [f2fs-dev] " Theodore Y. Ts'o
2019-11-06 4:05 ` Eric Biggers [this message]
2019-11-06 4:05 ` Eric Biggers
2019-11-07 2:49 ` Theodore Y. Ts'o
2019-11-07 2:49 ` [f2fs-dev] " Theodore Y. Ts'o
2019-10-24 21:54 ` [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies Eric Biggers
2019-10-24 21:54 ` [f2fs-dev] " Eric Biggers
2019-11-06 3:26 ` Theodore Y. Ts'o
2019-11-06 3:26 ` [f2fs-dev] " Theodore Y. Ts'o
2019-10-24 21:54 ` [PATCH v2 3/3] f2fs: " Eric Biggers
2019-10-24 21:54 ` [f2fs-dev] " Eric Biggers
2019-11-01 18:33 ` Jaegeuk Kim
2019-11-01 18:33 ` [f2fs-dev] " Jaegeuk Kim
2019-11-01 18:02 ` [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers
2019-11-01 18:02 ` [f2fs-dev] " Eric Biggers
2019-11-06 21:04 ` Eric Biggers
2019-11-06 21:04 ` [f2fs-dev] " 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=20191106040519.GA705@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=jaegeuk@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 \
--cc=paulcrowley@google.com \
--cc=paullawrence@google.com \
--cc=satyat@google.com \
--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 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.