| Message ID | 20200721181012.39308-1-ebiggers@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | fscrypt: restrict IV_INO_LBLK_* to AES-256-XTS | expand |
On Tue, Jul 21, 2020 at 11:10:12AM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > IV_INO_LBLK_* exist only because of hardware limitations, and currently > the only known use case for them involves AES-256-XTS. Therefore, for > now only allow them in combination with AES-256-XTS. This way we don't > have to worry about them being combined with other encryption modes. > > (To be clear, combining IV_INO_LBLK_* with other encryption modes > *should* work just fine. It's just not being tested, so we can't be > 100% sure it works. So with no known use case, it's best to disallow it > for now, just like we don't allow other weird combinations like > AES-256-XTS contents encryption with Adiantum filenames encryption.) > > This can be relaxed later if a use case for other combinations arises. > > Fixes: b103fb7653ff ("fscrypt: add support for IV_INO_LBLK_64 policies") > Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies") > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > fs/crypto/policy.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c > index 8a8ad0e44bb8..8e667aadf271 100644 > --- a/fs/crypto/policy.c > +++ b/fs/crypto/policy.c > @@ -77,6 +77,20 @@ static bool supported_iv_ino_lblk_policy(const struct fscrypt_policy_v2 *policy, > struct super_block *sb = inode->i_sb; > int ino_bits = 64, lblk_bits = 64; > > + /* > + * IV_INO_LBLK_* exist only because of hardware limitations, and > + * currently the only known use case for them involves AES-256-XTS. > + * That's also all we test currently. For these reasons, for now only > + * allow AES-256-XTS here. This can be relaxed later if a use case for > + * IV_INO_LBLK_* with other encryption modes arises. > + */ > + if (policy->contents_encryption_mode != FSCRYPT_MODE_AES_256_XTS) { > + fscrypt_warn(inode, > + "Can't use %s policy with contents mode other than AES-256-XTS", > + type); > + return false; > + } > + > /* > * It's unsafe to include inode numbers in the IVs if the filesystem can > * potentially renumber inodes, e.g. via filesystem shrinking. > -- Applied to fscrypt.git#master for 5.9. - Eric
diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index 8a8ad0e44bb8..8e667aadf271 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -77,6 +77,20 @@ static bool supported_iv_ino_lblk_policy(const struct fscrypt_policy_v2 *policy, struct super_block *sb = inode->i_sb; int ino_bits = 64, lblk_bits = 64; + /* + * IV_INO_LBLK_* exist only because of hardware limitations, and + * currently the only known use case for them involves AES-256-XTS. + * That's also all we test currently. For these reasons, for now only + * allow AES-256-XTS here. This can be relaxed later if a use case for + * IV_INO_LBLK_* with other encryption modes arises. + */ + if (policy->contents_encryption_mode != FSCRYPT_MODE_AES_256_XTS) { + fscrypt_warn(inode, + "Can't use %s policy with contents mode other than AES-256-XTS", + type); + return false; + } + /* * It's unsafe to include inode numbers in the IVs if the filesystem can * potentially renumber inodes, e.g. via filesystem shrinking.