Re: [RFC PATCH] gcm - fix setkey cache coherence issues

[Radu Solea <radu.solea@nxp.com>]

On Jo, 2017-06-22 at 15:53 +0800, Herbert Xu wrote:
> On Thu, Jun 22, 2017 at 05:03:44AM +0000, Radu Solea wrote:
> > 
> > I'm adding ____cacheline_aligned to iv and result. That is done so
> > hash, iv and result never share a cache line.
> Yes but you're doing it in crypto/gcm.c which isn't even used by
> caam AFAIK.
> 
> Cheers,

My bad, I need to put this in context better. First, I saw this issue
with CAAM, but it has the potential to impact any implementation that
tries to access those fields through DMA. 

CAAM has a number of variations one of them is called CAAM LP, it
doesn't support GCM but it can offload ctr(aes). Which it tries to do,
but because of how this memory is allocated, when the CPU writes
result, the cache mechanism overwrites hash and iv with whatever was
there before the offload happened. This is not the only problem, DMA
writing two fields on the same cacheline is likely to cause issues too:

from https://www.kernel.org/doc/Documentation/DMA-API.txt
Memory coherency operates at a granularity called the cache
line width.  In order for memory mapped by this API to operate
correctly, the mapped region must begin exactly on a cache line
boundary and end exactly on one (to prevent two separately mapped
regions from sharing a single cache line).  Since the cache line size
may not be known at compile time, the API will not enforce this
requirement.  Therefore, it is recommended that driver writers who
don't take special care to determine the cache line size at run time
only map virtual regions that begin and end on page boundaries (which
are guaranteed also to be cache line boundaries).

There are two ways of fixing this AFAIK: the first is adding
cacheline_aligned so those fields don't fall into the same cacheline.
The second is to kzalloc hash and iv separately. kmalloc should honor
ARCH_DMA_MINALIGN which would make this issue go away. 

Cheers,
Radu.