On Fri, 31 May 2019 at 16:21, Horia Geanta <[email protected]> wrote: > > On 5/31/2019 11:14 AM, Ard Biesheuvel wrote: > > The CAAM driver currently violates an undocumented and slightly > > controversial requirement imposed by the crypto stack that a buffer > > referred to by the request structure via its virtual address may not > > be modified while any scatterlists passed via the same request > > structure are mapped for inbound DMA. > > > IMO this requirement developed while discussing current issue, > it did not exist a priori. >
I won't argue with that. > > This may result in errors like > > > > alg: aead: decryption failed on test 1 for > > gcm_base(ctr-aes-caam,ghash-generic): ret=74 > > alg: aead: Failed to load transform for gcm(aes): -2 > > > > on non-cache coherent systems, due to the fact that the GCM driver > > passes an IV buffer by virtual address which shares a cacheline with > > the auth_tag buffer passed via a scatterlist, resulting in corruption > > of the auth_tag when the IV is updated while the DMA mapping is live. > > > > Since the IV that is returned to the caller is only valid for CBC mode, > > and given that the in-kernel users of CBC (such as CTS) don't trigger the > > same issue as the GCM driver, let's just disable the output IV generation > > for all modes except CBC for the time being. > > > > Cc: Horia Geanta <[email protected]> > > Cc: Iuliana Prodan <[email protected]> > > Reported-by: Sascha Hauer <[email protected]> > > Signed-off-by: Ard Biesheuvel <[email protected]> > Link: > https://lore.kernel.org/linux-crypto/[email protected]/ > Reviewed-by: Horia Geanta <[email protected]> > > Unfortunately this does not apply cleanly to -stable, I'll send a backport > once it hits mainline. > Thanks.
