linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Kim Boojin <boojin.kim@samsung.com>
Subject: Re: [PATCH v6 1/9] block: Keyslot Manager for Inline Encryption
Date: Wed, 18 Dec 2019 12:13:33 -0800	[thread overview]
Message-ID: <20191218201333.GA47399@gmail.com> (raw)
In-Reply-To: <20191218145136.172774-2-satyat@google.com>

On Wed, Dec 18, 2019 at 06:51:28AM -0800, Satya Tangirala wrote:
> Inline Encryption hardware allows software to specify an encryption context
> (an encryption key, crypto algorithm, data unit num, data unit size, etc.)

These four things (key, algorithm, DUN, and data unit size) fully specify the
crypto that is done.  So the use of "etc." is a bit misleading.

> along with a data transfer request to a storage device, and the inline
> encryption hardware will use that context to en/decrypt the data. The
> inline encryption hardware is part of the storage device, and it
> conceptually sits on the data path between system memory and the storage
> device.
> 
> Inline Encryption hardware implementations often function around the
> concept of "keyslots". These implementations often have a limited number
> of "keyslots", each of which can hold an encryption context (we say that
> an encryption context can be "programmed" into a keyslot). Requests made
> to the storage device may have a keyslot associated with them, and the
> inline encryption hardware will en/decrypt the data in the requests using
> the encryption context programmed into that associated keyslot. As
> keyslots are limited, and programming keys may be expensive in many
> implementations, and multiple requests may use exactly the same encryption
> contexts, we introduce a Keyslot Manager to efficiently manage keyslots.
> We also introduce a blk_crypto_key, which will represent the key that's
> programmed into keyslots managed by keyslot managers. The keyslot manager
> also functions as the interface that upper layers will use to program keys
> into inline encryption hardware. For more information on the Keyslot
> Manager, refer to documentation found in block/keyslot-manager.c and
> linux/keyslot-manager.h.

Long paragraphs are hard to read.  Maybe split this into multiple paragraphs.

> +/**
> + * keyslot_manager_crypto_mode_supported() - Find out if a crypto_mode/data
> + *					     unit size combination is supported
> + *					     by a ksm.
> + * @ksm: The keyslot manager to check
> + * @crypto_mode: The crypto mode to check for.
> + * @data_unit_size: The data_unit_size for the mode.
> + *
> + * Calls and returns the result of the crypto_mode_supported function specified
> + * by the ksm.
> + *
> + * Context: Process context.
> + * Return: Whether or not this ksm supports the specified crypto_mode/
> + *	   data_unit_size combo.
> + */
> +bool keyslot_manager_crypto_mode_supported(struct keyslot_manager *ksm,
> +					   enum blk_crypto_mode_num crypto_mode,
> +					   unsigned int data_unit_size)
> +{
> +	if (!ksm)
> +		return false;
> +	if (WARN_ON(crypto_mode >= BLK_ENCRYPTION_MODE_MAX))
> +		return false;
> +	if (WARN_ON(!is_power_of_2(data_unit_size)))
> +		return false;
> +	return ksm->crypto_mode_supported[crypto_mode] & data_unit_size;
> +}

There's no crypto_mode_supported() function anymore, so the comment above this
function is outdated, including both the part that mentions
crypto_mode_supported() and the part that says "Process context".

Also, since C enums are signed, and there's already a check for invalid
crypto_mode, it might be a good idea to catch crypto_mode < 0 too:

	if (WARN_ON((unsigned int)crypto_mode >= BLK_ENCRYPTION_MODE_MAX))

> +/**
> + * keyslot_manager_evict_key() - Evict a key from the lower layer device.
> + * @ksm: The keyslot manager to evict from
> + * @key: The key to evict
> + *
> + * Find the keyslot that the specified key was programmed into, and evict that
> + * slot from the lower layer device if that slot is not currently in use.
> + *
> + * Context: Process context. Takes and releases ksm->lock.
> + * Return: 0 on success, -EBUSY if the key is still in use, or another
> + *	   -errno value on other error.
> + */
> +int keyslot_manager_evict_key(struct keyslot_manager *ksm,
> +			      const struct blk_crypto_key *key)
> +{
> +	int slot;
> +	int err;
> +	struct keyslot *slotp;
> +
> +	down_write(&ksm->lock);
> +	slot = find_keyslot(ksm, key);
> +	if (slot < 0) {
> +		err = slot;
> +		goto out_unlock;
> +	}

I think this function should return 0 (rather than fail with -ENOKEY) if the key
is not currently programmed into a keyslot.  Otherwise anyone who wants to print
a warning if key eviction failed will have to ignore the -ENOKEY error.

(Note that this change would require an small update to the function comment.)

- Eric

  reply	other threads:[~2019-12-18 20:13 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 14:51 [PATCH v6 0/9] Inline Encryption Support Satya Tangirala
2019-12-18 14:51 ` [PATCH v6 1/9] block: Keyslot Manager for Inline Encryption Satya Tangirala
2019-12-18 20:13   ` Eric Biggers [this message]
2020-01-17  9:10   ` Christoph Hellwig
2019-12-18 14:51 ` [PATCH v6 2/9] block: Add encryption context to struct bio Satya Tangirala
2019-12-18 21:10   ` Eric Biggers
2019-12-18 21:21   ` Darrick J. Wong
2019-12-18 21:25     ` Martin K. Petersen
2019-12-18 22:27       ` Eric Biggers
2019-12-19  0:47         ` Martin K. Petersen
2019-12-20  3:52           ` Eric Biggers
2020-01-07  4:35             ` Martin K. Petersen
2020-01-08 14:07           ` Christoph Hellwig
2020-01-08 17:26             ` Eric Biggers
2020-01-17  8:32               ` Christoph Hellwig
2020-01-18  5:11                 ` Eric Biggers
2020-01-21 22:05                   ` Satya Tangirala
2020-01-09  3:40             ` Martin K. Petersen
2020-01-14 21:24   ` Eric Biggers
2019-12-18 14:51 ` [PATCH v6 3/9] block: blk-crypto for Inline Encryption Satya Tangirala
2019-12-20  3:14   ` Eric Biggers
2019-12-20  5:10   ` Eric Biggers
2020-01-14 21:22   ` Eric Biggers
2019-12-18 14:51 ` [PATCH v6 4/9] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2020-01-17 12:31   ` Christoph Hellwig
2019-12-18 14:51 ` [PATCH v6 5/9] scsi: ufs: UFS crypto API Satya Tangirala
2019-12-20  4:48   ` Eric Biggers
2020-01-14 21:16     ` Eric Biggers
2020-01-17 13:51   ` Christoph Hellwig
2019-12-18 14:51 ` [PATCH v6 6/9] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2019-12-20  5:44   ` Eric Biggers
2020-01-17 13:58   ` Christoph Hellwig
2020-01-18  5:27     ` Eric Biggers
2020-02-05 18:07       ` Christoph Hellwig
2020-01-18  3:58   ` Eric Biggers
2020-02-05 20:47   ` Eric Biggers
2019-12-18 14:51 ` [PATCH v6 7/9] fscrypt: add inline encryption support Satya Tangirala
2020-01-14 21:12   ` Eric Biggers
2019-12-18 14:51 ` [PATCH v6 8/9] f2fs: " Satya Tangirala
2019-12-20  4:23   ` Eric Biggers
2019-12-18 14:51 ` [PATCH v6 9/9] ext4: " Satya Tangirala
2019-12-19  0:12   ` Eric Biggers
2019-12-19  0:31     ` Satya Tangirala
2019-12-22  0:16   ` Eric Biggers
2020-01-08 14:05 ` [PATCH v6 0/9] Inline Encryption Support Christoph Hellwig
2020-01-08 18:43   ` Satya Tangirala
2020-01-17  8:52     ` Christoph Hellwig
2020-02-01  0:53       ` Satya Tangirala
2020-02-03  9:15         ` Christoph Hellwig
2020-02-04  3:39           ` Satya Tangirala
2020-02-04 14:58             ` Christoph Hellwig
2020-02-04 21:21               ` Eric Biggers
2020-02-05  7:36                 ` Eric Biggers
2020-02-05 18:05                   ` Christoph Hellwig
2020-02-21 12:30                     ` Satya Tangirala
2020-02-21 14:20                       ` Christoph Hellwig

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=20191218201333.GA47399@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=satyat@google.com \
    /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).