From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Horia Geanta <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Sascha Hauer <s.hauer@pengutronix.de>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] crypto: caam - Do not overwrite IV
Date: Mon, 11 Feb 2019 18:28:36 +0100 [thread overview]
Message-ID: <CAKv+Gu9nzpefv=TVh23dqk6etgvZS_KUfHsaJ=hjwwtjckT8Gw@mail.gmail.com> (raw)
In-Reply-To: <VI1PR0402MB34851754919DFF6FD0FDA57D98640@VI1PR0402MB3485.eurprd04.prod.outlook.com>
On Mon, 11 Feb 2019 at 16:13, Horia Geanta <horia.geanta@nxp.com> wrote:
>
> On 2/8/2019 1:45 PM, Herbert Xu wrote:
> > On Fri, Feb 08, 2019 at 08:41:37AM +0000, Horia Geanta wrote:
> >>
> >> So if there is a real intention to support offloading skcipher, as this old
> >> commit suggests:
> >>
> >> 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers")
> >> This patch adds the necessary changes for GCM to be used with async
> >> ciphers. This would allow it to be used with hardware devices that
> >> support CTR.
> >>
> >> then we must take special care when building skcipher req->src and avoid having
> >> it's first entry (auth_tag[16] in crypto_gcm_req_priv_ctx structure) sharing a
> >> cache line with req->iv.
> >
> > Could you prepare a patch for this?
> >
> Yes, will do.
>
> Note that I am seeing the same issue on CCM.
>
> Also for GCM, besides auth_tag there is iauth_tag[16] buffer that is added in a
> 1-entry S/G in gcm_hash_len():
> sg_init_one(&pctx->sg, pctx->iauth_tag, 16);
>
Yes, but I suppose the issue only occurs when writing data from the
device, no? AFAICT, iauth_tag[] is passed into the device but never
updated by it.
> It looks like there other places where this happens, for e.g. "tail" member of
> poly_req (crypto/cacha20poly1305.c) in poly_tail():
> sg_set_buf(preq->src, &preq->tail, sizeof(preq->tail));
>
Same here. If it never occurs in the destination of the scatterlist,
it should be safe for non-cache coherent DMA (since DMA to the device
does not involve cache invalidation)
However, it would be nice if we could test this in some way ...
prev parent reply other threads:[~2019-02-11 17:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 6:12 [PATCH] crypto: caam - Do not overwrite IV Sascha Hauer
2019-02-04 12:26 ` Horia Geanta
2019-02-05 8:31 ` Sascha Hauer
2019-02-05 11:49 ` Horia Geanta
2019-02-08 7:16 ` Herbert Xu
2019-02-08 8:41 ` Horia Geanta
2019-02-08 8:55 ` Ard Biesheuvel
2019-02-08 11:44 ` Herbert Xu
2019-02-12 9:13 ` Ard Biesheuvel
2019-02-13 20:48 ` Horia Geanta
2019-02-13 21:15 ` Ard Biesheuvel
2019-02-08 11:45 ` Herbert Xu
2019-02-11 15:13 ` Horia Geanta
2019-02-11 17:28 ` Ard Biesheuvel [this message]
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+Gu9nzpefv=TVh23dqk6etgvZS_KUfHsaJ=hjwwtjckT8Gw@mail.gmail.com' \
--to=ard.biesheuvel@linaro.org \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=kernel@pengutronix.de \
--cc=linux-crypto@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=stable@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).