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,
linux-ext4@vger.kernel.org,
Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
Kuohong Wang <kuohong.wang@mediatek.com>,
Kim Boojin <boojin.kim@samsung.com>
Subject: Re: [PATCH v12 05/12] block: blk-crypto-fallback for Inline Encryption
Date: Wed, 13 May 2020 11:05:27 -0700 [thread overview]
Message-ID: <20200513180527.GE1243@sol.localdomain> (raw)
In-Reply-To: <20200430115959.238073-6-satyat@google.com>
On Thu, Apr 30, 2020 at 11:59:52AM +0000, 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. It also allows for
> testing without actual inline encryption hardware - in particular, it
> makes it possible to test the inline encryption code in ext4 and f2fs
> simply by running xfstests with the inlinecrypt mount option, which in
> turn allows for things like the regular upstream regression testing of
> ext4 to cover the inline encryption code paths. For more details, refer
> to Documentation/block/inline-encryption.rst.
>
> Signed-off-by: Satya Tangirala <satyat@google.com>
Generally looks good, you can add:
Reviewed-by: Eric Biggers <ebiggers@google.com>
A few comments below for when you resend. Also, can you split the paragraph
above into multiple? E.g.
Blk-crypto delegates...
This lets upper layers...
For more details, refer to...
> +static int blk_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
> + const struct blk_crypto_key *key,
> + unsigned int slot)
> +{
> + struct blk_crypto_keyslot *slotp = &blk_crypto_keyslots[slot];
> + const enum blk_crypto_mode_num crypto_mode =
> + key->crypto_cfg.crypto_mode;
> + int err;
> +
> + if (crypto_mode != slotp->crypto_mode &&
> + slotp->crypto_mode != BLK_ENCRYPTION_MODE_INVALID)
> + blk_crypto_evict_keyslot(slot);
> +
> + slotp->crypto_mode = crypto_mode;
> + err = crypto_skcipher_setkey(slotp->tfms[crypto_mode], key->raw,
> + key->size);
> + if (err) {
> + blk_crypto_evict_keyslot(slot);
> + return -EIO;
> + }
> + return 0;
> +}
Shouldn't this just return 'err'? Is there a good reason for EIO?
> +static bool blk_crypto_alloc_cipher_req(struct bio *src_bio,
> + struct blk_ksm_keyslot *slot,
> + struct skcipher_request **ciph_req_ret,
> + struct crypto_wait *wait)
> +{
> + struct skcipher_request *ciph_req;
> + const struct blk_crypto_keyslot *slotp;
> + int keyslot_idx = blk_ksm_get_slot_idx(slot);
> +
> + slotp = &blk_crypto_keyslots[keyslot_idx];
> + ciph_req = skcipher_request_alloc(slotp->tfms[slotp->crypto_mode],
> + GFP_NOIO);
> + if (!ciph_req) {
> + src_bio->bi_status = BLK_STS_RESOURCE;
> + return false;
> + }
> +
> + skcipher_request_set_callback(ciph_req,
> + CRYPTO_TFM_REQ_MAY_BACKLOG |
> + CRYPTO_TFM_REQ_MAY_SLEEP,
> + crypto_req_done, wait);
> + *ciph_req_ret = ciph_req;
> +
> + return true;
> +}
I think it would be better to remove the 'src_bio' argument from here and make
the two callers set BLK_STS_RESOURCE instead. See e.g.
bio_crypt_check_alignment() which uses a similar convention.
> +/**
> + * blk_crypto_fallback_decrypt_endio - clean up bio w.r.t fallback decryption
> + *
> + * @bio: the bio to clean up.
> + *
> + * Restore bi_private and bi_end_io, and queue the bio for decryption into a
> + * workqueue, since this function will be called from an atomic context.
> + */
"clean up bio w.r.t fallback decryption" is misleading, since the main point of
this function is to queue the bio for decryption. How about:
/**
* blk_crypto_fallback_decrypt_endio - queue bio for fallback decryption
*
* @bio: the bio to queue
*
* Restore bi_private and bi_end_io, and queue the bio for decryption into a
* workqueue, since this function will be called from an atomic context.
*/
> +bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr)
> +{
> + struct bio *bio = *bio_ptr;
> + struct bio_crypt_ctx *bc = bio->bi_crypt_context;
> + struct bio_fallback_crypt_ctx *f_ctx;
> +
> + if (!tfms_inited[bc->bc_key->crypto_cfg.crypto_mode]) {
> + bio->bi_status = BLK_STS_IOERR;
> + return false;
> + }
This can only happen if the user forgot to call blk_crypto_start_using_key().
And if someone does that, it might be hard for them to understand why they're
getting IOERR. A WARN_ON_ONCE() and a comment would help:
if (WARN_ON_ONCE(!tfms_inited[bc->bc_key->crypto_cfg.crypto_mode])) {
/* User didn't call blk_crypto_start_using_key() first */
bio->bi_status = BLK_STS_IOERR;
return false;
}
This would be similar to how __blk_crypto_bio_prep() does
WARN_ON_ONCE(!bio_has_data(bio)) to catch another type of usage error.
> +/*
> + * Prepare blk-crypto-fallback for the specified crypto mode.
> + * Returns -ENOPKG if the needed crypto API support is missing.
> + */
> +int blk_crypto_fallback_start_using_mode(enum blk_crypto_mode_num mode_num)
> +{
> + const char *cipher_str = blk_crypto_modes[mode_num].cipher_str;
> + struct blk_crypto_keyslot *slotp;
> + unsigned int i;
> + int err = 0;
> +
> + /*
> + * Fast path
> + * Ensure that updates to blk_crypto_keyslots[i].tfms[mode_num]
> + * for each i are visible before we try to access them.
> + */
> + if (likely(smp_load_acquire(&tfms_inited[mode_num])))
> + return 0;
> +
> + mutex_lock(&tfms_init_lock);
> + err = blk_crypto_fallback_init();
> + if (err)
> + goto out;
> +
> + if (tfms_inited[mode_num])
> + goto out;
It would make more sense to check tfms_inited[mode_num] immediately after
acquiring the mutex, given that it's checked before.
- Eric
next prev parent reply other threads:[~2020-05-13 18:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 11:59 [PATCH v12 00/12] Inline Encryption Support Satya Tangirala
2020-04-30 11:59 ` [PATCH v12 01/12] Documentation: Document the blk-crypto framework Satya Tangirala
2020-05-13 16:47 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 02/12] block: Keyslot Manager for Inline Encryption Satya Tangirala
2020-05-13 13:35 ` Christoph Hellwig
2020-05-13 16:59 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 03/12] block: Inline encryption support for blk-mq Satya Tangirala
2020-05-13 13:36 ` Christoph Hellwig
2020-05-13 17:27 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 04/12] block: Make blk-integrity preclude hardware inline encryption Satya Tangirala
2020-05-13 13:37 ` Christoph Hellwig
2020-05-13 17:30 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 05/12] block: blk-crypto-fallback for Inline Encryption Satya Tangirala
2020-05-13 18:05 ` Eric Biggers [this message]
2020-04-30 11:59 ` [PATCH v12 06/12] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2020-05-13 18:16 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 07/12] scsi: ufs: UFS crypto API Satya Tangirala
2020-05-13 18:16 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 08/12] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2020-05-13 18:19 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 09/12] fs: introduce SB_INLINECRYPT Satya Tangirala
2020-04-30 11:59 ` [PATCH v12 10/12] fscrypt: add inline encryption support Satya Tangirala
2020-04-30 17:04 ` Eric Biggers
2020-04-30 11:59 ` [PATCH v12 11/12] f2fs: " Satya Tangirala
2020-04-30 11:59 ` [PATCH v12 12/12] ext4: " Satya Tangirala
2020-04-30 17:02 ` [PATCH v12 00/12] 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=20200513180527.GE1243@sol.localdomain \
--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-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).