On Mon, 11 Feb 2019 at 16:13, Horia Geanta <horia.gea...@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 ...
