linux-fscrypt.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/3] fscrypt: Add metadata encryption support
Date: Wed, 7 Oct 2020 13:52:21 -0700	[thread overview]
Message-ID: <20201007205221.GA1530638@gmail.com> (raw)
In-Reply-To: <20201005073606.1949772-3-satyat@google.com>

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@google.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.

> 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?

> +/**
> + * 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".

> + * @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.

- Eric

  reply	other threads:[~2020-10-07 20:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05  7:36 [PATCH 0/3] add support for metadata encryption to F2FS Satya Tangirala
2020-10-05  7:36 ` [PATCH 1/3] fscrypt, f2fs: replace fscrypt_get_devices with fscrypt_get_device Satya Tangirala
2020-10-05  7:36 ` [PATCH 2/3] fscrypt: Add metadata encryption support Satya Tangirala
2020-10-07 20:52   ` Eric Biggers [this message]
2020-10-07 23:28     ` Satya Tangirala
2020-10-08 17:05       ` Eric Biggers
2020-10-05  7:36 ` [PATCH 3/3] f2fs: " Satya Tangirala
2020-10-05 10:19   ` kernel test robot
2020-10-07 21:20   ` Eric Biggers
2020-10-08  0:31     ` Satya Tangirala
2020-10-05  7:43 ` [PATCH 0/3] add support for metadata encryption to F2FS Satya Tangirala
2020-10-07 21:00 ` Eric Biggers
2020-10-07 22:05   ` Satya Tangirala
2020-10-08 17:01     ` Eric Biggers
2020-10-10  9:53 ` Chao Yu
2020-12-17 15:44   ` Satya Tangirala
2020-12-18  9:02     ` Chao Yu
2020-12-18 11:53       ` Satya Tangirala
2020-12-22 11:47         ` Chao Yu
2020-12-24 10:13           ` Satya Tangirala
2020-12-25  9:31             ` Chao Yu

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=20201007205221.GA1530638@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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).