From: Randy Dunlap <rdunlap@infradead.org>
To: Satya Tangirala <satyat@google.com>,
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,
linux-ext4@vger.kernel.org
Cc: Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
Kuohong Wang <kuohong.wang@mediatek.com>,
Kim Boojin <boojin.kim@samsung.com>
Subject: Re: [PATCH v7 3/9] block: blk-crypto-fallback for Inline Encryption
Date: Fri, 21 Feb 2020 08:51:09 -0800 [thread overview]
Message-ID: <9c81a71f-9322-7f89-fa3d-4511f162d085@infradead.org> (raw)
In-Reply-To: <20200221115050.238976-4-satyat@google.com>
On 2/21/20 3:50 AM, Satya Tangirala wrote:
> Blk-crypto delegates crypto operations to inline encryption hardware when
> available. The separately configurable blk-crypto-fallback contains a
> software fallback to the kernel crypto API - when enabled, blk-crypto
> will use this fallback for en/decryption when inline encryption hardware is
> not available. This lets upper layers not have to worry about whether or
> not the underlying device has support for inline encryption before
> deciding to specify an encryption context for a bio, and also allows for
> testing without actual inline encryption hardware. For more details, refer
> to Documentation/block/inline-encryption.rst.
>
> Signed-off-by: Satya Tangirala <satyat@google.com>
> ---
> Documentation/block/index.rst | 1 +
> Documentation/block/inline-encryption.rst | 162 ++++++
> block/Kconfig | 10 +
> block/Makefile | 1 +
> block/bio-integrity.c | 2 +-
> block/blk-crypto-fallback.c | 673 ++++++++++++++++++++++
> block/blk-crypto-internal.h | 32 +
> block/blk-crypto.c | 43 +-
> include/linux/blk-crypto.h | 17 +-
> include/linux/blk_types.h | 6 +
> 10 files changed, 938 insertions(+), 9 deletions(-)
> create mode 100644 Documentation/block/inline-encryption.rst
> create mode 100644 block/blk-crypto-fallback.c
> diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst
> new file mode 100644
> index 000000000000..02abea993975
> --- /dev/null
> +++ b/Documentation/block/inline-encryption.rst
> @@ -0,0 +1,162 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=================
> +Inline Encryption
> +=================
> +
> +Background
> +==========
> +
> +Inline encryption hardware sit logically between memory and the disk, and can
sits
> +en/decrypt data as it goes in/out of the disk. Inline encryption hardware have a
has
> +fixed number of "keyslots" - slots into which encryption contexts (i.e. the
> +encryption key, encryption algorithm, data unit size) can be programmed by the
> +kernel at any time. Each request sent to the disk can be tagged with the index
> +of a keyslot (and also a data unit number to act as an encryption tweak), and
> +the inline encryption hardware will en/decrypt the data in the request with the
> +encryption context programmed into that keyslot. This is very different from
> +full disk encryption solutions like self encrypting drives/TCG OPAL/ATA
> +Security standards, since with inline encryption, any block on disk could be
> +encrypted with any encryption context the kernel chooses.
> +
> +
> +Objective
> +=========
> +
...
> +
> +
> +Constraints and notes
> +=====================
> +
> +- IE hardware have a limited number of "keyslots" that can be programmed
has
> + with an encryption context (key, algorithm, data unit size, etc.) at any time.
> + One can specify a keyslot in a data request made to the device, and the
> + device will en/decrypt the data using the encryption context programmed into
> + that specified keyslot. When possible, we want to make multiple requests with
> + the same encryption context share the same keyslot.
> +
...
> +
> +
> +Design
> +======
> +
> +We add a :c:type:`struct bio_crypt_ctx` to :c:type:`struct bio` that can
> +represent an encryption context, because we need to be able to pass this
> +encryption context from the FS layer to the device driver to act upon.
> +
> +While IE hardware works on the notion of keyslots, the FS layer has no
> +knowledge of keyslots - it simply wants to specify an encryption context to
> +use while en/decrypting a bio.
> +
> +We introduce a keyslot manager (KSM) that handles the translation from
> +encryption contexts specified by the FS to keyslots on the IE hardware.
> +This KSM also serves as the way IE hardware can expose their capabilities to
its
> +upper layers. The generic mode of operation is: each device driver that wants
> +to support IE will construct a KSM and set it up in its struct request_queue.
> +Upper layers that want to use IE on this device can then use this KSM in
> +the device's struct request_queue to translate an encryption context into
> +a keyslot. The presence of the KSM in the request queue shall be used to mean
> +that the device supports IE.
> +
...
Hi Satya,
ISTM that we disagree on whether "hardware" is singular or plural. ;)
My interface search foo (FWIW) says that "hardware" has no plural version.
Anyway, my best evidence is in your intro/commit message, where it says:
"when inline encryption hardware is not available",
so it must be singular. :)
cheers.
--
~Randy
next prev parent reply other threads:[~2020-02-21 16:51 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 11:50 [PATCH v7 0/9] Inline Encryption Support Satya Tangirala
2020-02-21 11:50 ` [PATCH v7 1/9] block: Keyslot Manager for Inline Encryption Satya Tangirala
2020-02-21 17:04 ` Christoph Hellwig
2020-02-21 17:31 ` Christoph Hellwig
2020-02-27 18:14 ` Eric Biggers
2020-02-27 21:25 ` Satya Tangirala
2020-03-05 16:11 ` Christoph Hellwig
2020-02-27 18:48 ` Eric Biggers
2020-02-21 11:50 ` [PATCH v7 2/9] block: Inline encryption support for blk-mq Satya Tangirala
2020-02-21 17:22 ` Christoph Hellwig
2020-02-22 0:52 ` Satya Tangirala
2020-02-24 23:34 ` Christoph Hellwig
2020-02-27 18:25 ` Eric Biggers
2020-02-21 11:50 ` [PATCH v7 3/9] block: blk-crypto-fallback for Inline Encryption Satya Tangirala
2020-02-21 16:51 ` Randy Dunlap [this message]
2020-02-21 17:25 ` Christoph Hellwig
2020-02-21 17:35 ` Christoph Hellwig
2020-02-21 18:34 ` Eric Biggers
2020-02-24 23:36 ` Christoph Hellwig
2020-02-27 19:25 ` Eric Biggers
2020-02-21 11:50 ` [PATCH v7 4/9] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2020-02-21 11:50 ` [PATCH v7 5/9] scsi: ufs: UFS crypto API Satya Tangirala
2020-02-22 4:59 ` Eric Biggers
2020-02-21 11:50 ` [PATCH v7 6/9] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2020-02-21 17:22 ` Christoph Hellwig
2020-02-21 18:11 ` Eric Biggers
2020-02-23 13:47 ` Stanley Chu
2020-02-24 23:37 ` Christoph Hellwig
2020-02-25 7:21 ` Stanley Chu
2020-02-26 1:12 ` Eric Biggers
2020-02-26 6:43 ` Stanley Chu
2020-03-02 9:17 ` Stanley Chu
2020-02-21 11:50 ` [PATCH v7 7/9] fscrypt: add inline encryption support Satya Tangirala
2020-02-21 18:40 ` Eric Biggers
2020-02-22 5:39 ` Eric Biggers
2020-02-26 0:30 ` Eric Biggers
2020-02-21 11:50 ` [PATCH v7 8/9] f2fs: " Satya Tangirala
2020-02-21 11:50 ` [PATCH v7 9/9] ext4: " Satya Tangirala
2020-02-22 5:21 ` Eric Biggers
2020-02-21 17:16 ` [PATCH v7 0/9] Inline Encryption Support 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=9c81a71f-9322-7f89-fa3d-4511f162d085@infradead.org \
--to=rdunlap@infradead.org \
--cc=bmuthuku@qti.qualcomm.com \
--cc=boojin.kim@samsung.com \
--cc=kuohong.wang@mediatek.com \
--cc=linux-block@vger.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=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).