From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Eric Biggers <ebiggers@google.com>,
linux-fscrypt@vger.kernel.org,
Gilad Ben-Yossef <gilad@benyossef.com>,
device-mapper development <dm-devel@redhat.com>,
Milan Broz <gmazyland@gmail.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 1/7] crypto: essiv - create wrapper template for ESSIV generation
Date: Thu, 27 Jun 2019 09:04:10 +0200 [thread overview]
Message-ID: <CAKv+Gu8ivcjgM0hjLHrf55kWHpoV8ZYYYLkPuaapMe6Yj37Zbg@mail.gmail.com> (raw)
In-Reply-To: <20190626204047.32131-2-ard.biesheuvel@linaro.org>
On Wed, 26 Jun 2019 at 22:40, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> Implement a template that wraps a (skcipher,cipher,shash) or
> (aead,cipher,shash) tuple so that we can consolidate the ESSIV handling
> in fscrypt and dm-crypt and move it into the crypto API. This will result
> in better test coverage, and will allow future changes to make the bare
> cipher interface internal to the crypto subsystem, in order to increase
> robustness of the API against misuse.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> crypto/Kconfig | 4 +
> crypto/Makefile | 1 +
> crypto/essiv.c | 636 ++++++++++++++++++++
> 3 files changed, 641 insertions(+)
>
...
> diff --git a/crypto/essiv.c b/crypto/essiv.c
> new file mode 100644
> index 000000000000..fddf6dcc3823
> --- /dev/null
> +++ b/crypto/essiv.c
> @@ -0,0 +1,636 @@
...
> +static void essiv_aead_done(struct crypto_async_request *areq, int err)
> +{
> + struct aead_request *req = areq->data;
> + struct essiv_aead_request_ctx *rctx = aead_request_ctx(req);
> +
> + if (rctx->iv)
> + kfree(rctx->iv);
> + aead_request_complete(req, err);
> +}
> +
> +static int essiv_aead_crypt(struct aead_request *req, bool enc)
> +{
> + gfp_t gfp = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ? GFP_KERNEL
> + : GFP_ATOMIC;
> + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> + const struct essiv_tfm_ctx *tctx = crypto_aead_ctx(tfm);
> + struct essiv_aead_request_ctx *rctx = aead_request_ctx(req);
> + struct aead_request *subreq = &rctx->aead_req;
> + struct scatterlist *sg;
> + int err;
> +
> + crypto_cipher_encrypt_one(tctx->essiv_cipher, req->iv, req->iv);
> +
> + /*
> + * dm-crypt embeds the sector number and the IV in the AAD region, so
> + * we have to copy the converted IV into the source scatterlist before
> + * we pass it on. If the source and destination scatterlist pointers
> + * are the same, we just update the IV copy in the AAD region in-place.
> + * However, if they are different, the caller is not expecting us to
> + * modify the memory described by the source scatterlist, and so we have
> + * to do this little dance to create a new scatterlist that backs the
> + * IV slot in the AAD region with a scratch buffer that we can freely
> + * modify.
> + */
> + rctx->iv = NULL;
> + if (req->src != req->dst) {
> + int ivsize = crypto_aead_ivsize(tfm);
> + int ssize = req->assoclen - ivsize;
> + u8 *iv;
> +
> + if (ssize < 0 || sg_nents_for_len(req->src, ssize) != 1)
> + return -EINVAL;
> +
> + if (enc) {
> + rctx->iv = iv = kmemdup(req->iv, ivsize, gfp);
This allocation is not really needed - I'll enlarge the request ctx
struct instead so I can incorporate it as an anonymous member.
> + if (!iv)
> + return -ENOMEM;
> + } else {
> + /*
> + * On the decrypt path, the ahash executes before the
> + * skcipher gets a chance to clobber req->iv with its
> + * output IV, so just map the buffer directly.
> + */
> + iv = req->iv;
> + }
> +
> + sg_init_table(rctx->sg, 4);
> + sg_set_page(rctx->sg, sg_page(req->src), ssize, req->src->offset);
> + sg_set_buf(rctx->sg + 1, iv, ivsize);
> + sg = scatterwalk_ffwd(rctx->sg + 2, req->src, req->assoclen);
> + if (sg != rctx->sg + 2)
> + sg_chain(rctx->sg, 3, sg);
> + sg = rctx->sg;
> + } else {
> + scatterwalk_map_and_copy(req->iv, req->dst,
> + req->assoclen - crypto_aead_ivsize(tfm),
> + crypto_aead_ivsize(tfm), 1);
> + sg = req->src;
> + }
> +
> + aead_request_set_tfm(subreq, tctx->u.aead);
> + aead_request_set_ad(subreq, req->assoclen);
> + aead_request_set_callback(subreq, aead_request_flags(req),
> + essiv_aead_done, req);
> + aead_request_set_crypt(subreq, sg, req->dst, req->cryptlen, req->iv);
> +
> + err = enc ? crypto_aead_encrypt(subreq) :
> + crypto_aead_decrypt(subreq);
> +
> + if (rctx->iv && err != -EINPROGRESS)
> + kfree(rctx->iv);
> +
> + return err;
> +}
> +
...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-27 7:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-26 20:40 [PATCH v5 0/7] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-06-26 20:40 ` [PATCH v5 1/7] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-06-27 7:04 ` Ard Biesheuvel [this message]
2019-06-26 20:40 ` [PATCH v5 2/7] fs: crypto: invoke crypto API for ESSIV handling Ard Biesheuvel
2019-06-27 16:39 ` Eric Biggers
2019-06-26 20:40 ` [PATCH v5 3/7] md: dm-crypt: infer ESSIV block cipher from cipher string directly Ard Biesheuvel
2019-06-26 20:40 ` [PATCH v5 4/7] md: dm-crypt: switch to ESSIV crypto API template Ard Biesheuvel
2019-06-26 20:40 ` [PATCH v5 5/7] crypto: essiv - add test vector for essiv(cbc(aes), aes, sha256) Ard Biesheuvel
2019-06-27 16:32 ` [PATCH v5 5/7] crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256) Eric Biggers
2019-06-26 20:40 ` [PATCH v5 6/7] crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk Ard Biesheuvel
2019-06-26 20:40 ` [PATCH v5 7/7] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel
2019-06-27 16:40 ` 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=CAKv+Gu8ivcjgM0hjLHrf55kWHpoV8ZYYYLkPuaapMe6Yj37Zbg@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=dm-devel@redhat.com \
--cc=ebiggers@google.com \
--cc=gilad@benyossef.com \
--cc=gmazyland@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/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).