linux-kernel - Re: [PATCH] crypto: marvell/cesa - Avoid empty transfer descriptor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <23fe1dec-032a-41fb-8e60-3a1b6c098c4e@app.fastmail.com>
Date: Wed, 21 May 2025 11:58:49 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Herbert Xu" <herbert@...dor.apana.org.au>,
 "Corentin Labbe" <clabbe.montjoie@...il.com>
Cc: "Klaus Kudielka" <klaus.kudielka@...il.com>,
 "Eric Biggers" <ebiggers@...nel.org>, regressions@...ts.linux.dev,
 linux-kernel@...r.kernel.org,
 "Linux Crypto Mailing List" <linux-crypto@...r.kernel.org>,
 "'bbrezillon@...nel.org'" <bbrezillon@...nel.org>,
 "EBALARD Arnaud" <Arnaud.Ebalard@....gouv.fr>,
 "Romain Perier" <romain.perier@...il.com>
Subject: Re: [PATCH] crypto: marvell/cesa - Avoid empty transfer descriptor

On Wed, May 21, 2025, at 11:16, Herbert Xu wrote:
> On Wed, May 21, 2025 at 01:06:43PM +0800, Herbert Xu wrote:
>>
>> Can you please try this patch to see if it makes a difference?
>
> Actually, please try this one instead.
>

> 
>  	memcpy(ahashdreq->cache, creq->cache, creq->cache_ptr);
> +	arch_sync_dma_for_device(ahashdreq->cache_dma, creq->cache_ptr, 
> DMA_TO_DEVICE);
> 
>  	return mv_cesa_dma_add_data_transfer(chain,
>  					     CESA_SA_DATA_SRAM_OFFSET,


I did not see the entire background of the discussion, but would
point out that this is not supposed to work at all:

- arch_sync_dma_for_device() is not callable from drivers,
  on a streaming mapping one would instead have to call
  dma_sync_single_for_device() with the correct device.

- in the mainline kernel, the memory comes from a coherent
  dma pool, and the devices that the driver binds (Marvell
  Armada 32-bit) do not have cache-coherent DMA, so the
  buffer itself is in an uncached page and you must never
  do cache management operations on it.

If the allocation is changed from a coherent dma pool to
a dma_alloc_noncoherent() call, then the
dma_sync_single_for_device() would indeed be the correct
interface for passing the buffer to the device, but for
a coherent buffer, a simple 'dma_wmb()' as you suggested
earlier would be the right interface.

Depending on the size of the data, the streaming mapping
would likely be significantly faster than the coherent
dma pool object.

      Arnd