Message-ID: <20201007232806.GB2544297@google.com>
Date:   Wed, 7 Oct 2020 23:28:06 +0000
From:   Satya Tangirala <satyat@...gle.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     "Theodore Y . Ts'o" <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
        linux-kernel@...r.kernel.org, linux-fscrypt@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 2/3] fscrypt: Add metadata encryption support

On Wed, Oct 07, 2020 at 01:52:21PM -0700, Eric Biggers wrote:
> On Mon, Oct 05, 2020 at 07:36:05AM +0000, Satya Tangirala wrote:
> > Introduces functions that help with metadata encryption.
> > 
> > In particular, we introduce:
> > 
> > fscrypt_setup_metadata_encryption() - filesystems should call this function
> > to set up metadata encryption on a super block with the encryption
> > algorithm (the desired FSCRYPT_MODE_*) and the key descriptor of the
> > encryption key. The key descriptor is looked up in the logon keyring of the
> > current session using "fscrypt:" as the descriptor prefix.
> > 
> > fscrypt_metadata_crypt_bio() - filesystems should call this function on a
> > bio that it wants metadata crypted. This function will set a bio-crypt-ctx
> > on the bio if the metadata key was set up with
> > fscrypt_setup_metadata_encryption(). The DUN for the first block in the bio
> > is the offset of that block from the start of the filesystem.
> > 
> > fscrypt_free_metadata_encryption() - this function should be called when
> > the super block is being freed. It ensures that the metadata encryption key
> > is evicted, if necessary, from devices.
> > 
> > Note that the filesystem (rather than fscrypt) controls precisely which
> > blocks are encrypted with the metadata encryption key and which blocks are
> > encrypted with other keys/not encrypted at all. Fscrypt only provides some
> > convenience functions that ultimately help encrypt a bio with the metadata
> > encryption key when desired.
> > 
> > Signed-off-by: Satya Tangirala <satyat@...gle.com>
> > ---
> >  fs/crypto/Kconfig           |   6 +
> >  fs/crypto/Makefile          |   1 +
> >  fs/crypto/fscrypt_private.h |  19 ++++
> >  fs/crypto/inline_crypt.c    |  18 ---
> >  fs/crypto/metadata_crypt.c  | 220 ++++++++++++++++++++++++++++++++++++
> >  include/linux/fs.h          |   3 +
> >  include/linux/fscrypt.h     |  47 ++++++++
> >  7 files changed, 296 insertions(+), 18 deletions(-)
> >  create mode 100644 fs/crypto/metadata_crypt.c
> > 
> > diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig
> > index a5f5c30368a2..3010e91f6659 100644
> > --- a/fs/crypto/Kconfig
> > +++ b/fs/crypto/Kconfig
> > @@ -30,3 +30,9 @@ config FS_ENCRYPTION_INLINE_CRYPT
> >  	depends on FS_ENCRYPTION && BLK_INLINE_ENCRYPTION
> >  	help
> >  	  Enable fscrypt to use inline encryption hardware if available.
> > +
> > +config FS_ENCRYPTION_METADATA
> > +	bool "Enable metadata encryption with fscrypt"
> > +	depends on FS_ENCRYPTION && BLK_INLINE_ENCRYPTION
> > +	help
> > +	  Enable fscrypt to encrypt metadata.
> 
> This needs Kconfig help text to describe what this feature is and why anyone
> would want to enable it.  It also needs an update to
> Documentation/filesystems/fscrypt.rst, and a test in xfstests that tests that
> the encryption is being done correctly.
> 
Sure. I forgot to mention, fwiw I did hack xfstests to enable metadata
encryption on each device to try to test the code, and also some other
informal tests, but as you point out, I should send out actual xfstests
to test this.
> > diff --git a/fs/crypto/metadata_crypt.c b/fs/crypto/metadata_crypt.c
> > new file mode 100644
> > index 000000000000..5e16df130509
> > --- /dev/null
> > +++ b/fs/crypto/metadata_crypt.c
> > @@ -0,0 +1,220 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Metadata encryption support for fscrypt
> > + *
> > + * Copyright 2020 Google LLC
> > + */
> > +
> > +#include <keys/user-type.h>
> > +#include <linux/blk-crypto.h>
> > +#include <linux/blkdev.h>
> > +#include <linux/buffer_head.h>
> > +#include <linux/sched/mm.h>
> > +
> > +#include "fscrypt_private.h"
> > +
> > +/* TODO: mostly copied from keysetup_v1.c - maybe refactor this function */
> > +static int fscrypt_metadata_get_key_from_id(const char *prefix,
> > +					    char *descriptor_hex,
> > +					    unsigned int min_keysize,
> > +					    char *raw_key)
> > +{
> > +	char *description;
> > +	struct key *key;
> > +	const struct user_key_payload *ukp;
> > +	const struct fscrypt_key *payload;
> > +	int err = -ENOKEY;
> > +
> > +	if (strlen(descriptor_hex) != FSCRYPT_KEY_DESCRIPTOR_SIZE * 2)
> > +		return -EINVAL;
> > +
> > +	description = kasprintf(GFP_NOFS, "%s%s", prefix, descriptor_hex);
> > +	if (!description)
> > +		return -ENOMEM;
> > +
> > +	key = request_key(&key_type_logon, description, NULL);
> > +	kfree(description);
> > +	if (IS_ERR(key))
> > +		return PTR_ERR(key);
> > +
> > +	down_read(&key->sem);
> > +	ukp = user_key_payload_locked(key);
> > +
> > +	if (!ukp) /* was the key revoked before we acquired its semaphore? */
> > +		goto out;
> > +
> > +	payload = (const struct fscrypt_key *)ukp->data;
> 
> 'struct fscrypt_key' was a mistake.  How about having the key payload just be
> the raw key?
> 
> Or are you thinking that reserved fields will be needed?
> 
Ah, I should've just made it the raw key to start with - I can't think
of any reserved fields we might need when specifying the key (I thought
we might need something like that when we try to support hardware
wrapped keys with metadata encryption, but we could use extra fields in
the superblock for that).

> > +/**
> > + * fscrypt_setup_metadata_encryption() - prepare a super_block for metadata
> > + *					 encryption
> > + * @sb: The super_block to set up metadata encryption for
> > + * @key_desc_hex: The key descriptor (in hex) to look for in the logon keyring.
> 
> There's no such thing as a "logon keyring".  I think you mean "look for a logon
> key in the process-subscribed keyrings".
> 
Ah, I see - thanks!
> > + * @fscrypt_mode_num: The FSCRYPT_MODE_* to use as the encryption algorithm.
> > + *
> > + * Return: 0 on success, negative number on error.
> > + */
> > +int fscrypt_setup_metadata_encryption(struct super_block *sb,
> > +				      char *key_desc_hex,
> > +				      int fscrypt_mode_num)
> > +{
> > +	int err = 0;
> > +	enum blk_crypto_mode_num crypto_mode;
> > +	unsigned int lblk_bits = 64;
> > +	unsigned int dun_bytes;
> > +	unsigned int dummy;
> > +	char raw_key[FSCRYPT_MAX_KEY_SIZE];
> 
> For binary data, prefer 'u8' to 'char'.
> 
> > +
> > +	if (fscrypt_mode_num > __FSCRYPT_MODE_MAX || fscrypt_mode_num < 0 ||
> > +	    !fscrypt_modes[fscrypt_mode_num].cipher_str) {
> > +		fscrypt_warn(NULL, "Invalid fscrypt mode %d specified for metadata encryption.",
> > +			     fscrypt_mode_num);
> > +		return -EOPNOTSUPP;
> > +	}
> 
> The filenames-only encryption modes (FSCRYPT_MODE_AES_256_CTS and
> FSCRYPT_MODE_AES_128_CTS) will pass this check, which seems undesired.
> 
> > +
> > +	if (sb->s_cop->get_ino_and_lblk_bits)
> > +		sb->s_cop->get_ino_and_lblk_bits(sb, &dummy, &lblk_bits);
> > +	dun_bytes = DIV_ROUND_UP(lblk_bits, 8);
> > +
> > +	if (fscrypt_modes[fscrypt_mode_num].ivsize < dun_bytes) {
> > +		fscrypt_warn(NULL, "The fscrypt mode only supports %d DUN bytes, but FS requires support for %d DUN bytes.",
> > +			     fscrypt_modes[fscrypt_mode_num].ivsize, dun_bytes);
> > +		return -EOPNOTSUPP;
> > +	}
> 
> lblk_bits is the number of bits used to represent file logical block numbers
> (e.g. ext4_lblk_t).  That's different from the filesystem-wide block number
> (e.g. ext4_fsblk_t), which is what metadata encryption will use.
> 
> > +	crypto_mode = fscrypt_modes[fscrypt_mode_num].blk_crypto_mode;
> > +
> > +	err = fscrypt_metadata_get_key_from_id(
> > +					FSCRYPT_KEY_DESC_PREFIX,
> > +					key_desc_hex,
> > +					fscrypt_modes[fscrypt_mode_num].keysize,
> > +					raw_key);
> > +	if (err)
> > +		goto out;
> 
> This is allowing for the key to be longer than the provided keysize, in which
> case only a prefix of the key is used.
> 
> It should require the exact keysize instead.
> 
> > +
> > +	sb->s_metadata_key = kzalloc(sizeof(*sb->s_metadata_key), GFP_NOFS);
> 
> No need for GFP_NOFS here.
> 
> > +/**
> > + * fscrypt_free_metadata_encryption() - free metadata encryption fields in
> > + *					super_block.
> > + * @sb: The super_block to free metatdata encryption fields from
> > + */
> > +void fscrypt_free_metadata_encryption(struct super_block *sb)
> > +{
> > +	int num_devices;
> > +	int i;
> > +	struct request_queue *q;
> > +
> > +	if (!sb->s_metadata_key)
> > +		return;
> > +
> > +	num_devices = fscrypt_get_num_devices(sb);
> > +
> > +	for (i = 0; i < num_devices; i++) {
> > +		q = fscrypt_get_device(sb, i);
> > +		if (WARN_ON(!q))
> > +			continue;
> > +		blk_crypto_evict_key(q, sb->s_metadata_key);
> > +	}
> > +
> > +	memzero_explicit(sb->s_metadata_key, sizeof(*sb->s_metadata_key));
> > +	kzfree(sb->s_metadata_key);
> > +	sb->s_metadata_key = NULL;
> > +}
> 
> kfree_sensitive(), not kzfree().
> 
> Also, memzero_explicit() is redundant.
> 
> > +/**
> > + * fscrypt_metadata_crypt_bio() - Add metadata encryption context to bio.
> > + *
> > + * @bio: The bio to add the encryption context to
> > + * @lblk: The logical block number within the filesystem at which this bio
> > + *	  starts reading/writing data.
> 
> Should be:
> 
>    @fsblk: The block number within the filesystem ...
> 
> > + * @sb: The superblock of the filesystem
> > + * @gfp_mask: gfp_mask for bio_crypt_context allocation
> > + */
> > +void fscrypt_metadata_crypt_bio(struct bio *bio, u64 lblk,
> > +				struct super_block *sb, gfp_t gfp_mask)
> > +{
> > +	u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE] = { 0 };
> > +
> > +	if (!sb->s_metadata_key)
> > +		return;
> > +
> > +	dun[0] = lblk;
> > +	bio_crypt_set_ctx(bio, sb->s_metadata_key, dun, gfp_mask);
> > +}
> 
> Perhaps fscrypt_set_bio_crypt_ctx() should call this?  It seems there should be
> a single function that filesystems can call that handles setting the
> bio_crypt_ctx for both file contents and metadata encryption.
> 
I mistakenly dismissed this idea when I was coding this up :( - I'll do
this for the next version... I think it'll also make supporting direct I/O
easier in future :) . Also, I might require FS_ENCRYPTION_INLINE_CRYPT
when enabling FS_ENCRYPTION_METADATA to maybe make the code slightly
cleaner (unless there's a reason we want to support metadata encryption
without FS inline encryption being enabled?).
> - Eric

Powered by blists - more mailing lists