linux-kernel - Re: [PATCH] spi: Ensure memory used for spi_write_then

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 for Android: free password hash cracker in your pocket

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

Message-Id: <6a3a4b10-f51b-43e2-8281-057f6751424b@app.fastmail.com>
Date: Fri, 21 Mar 2025 20:42:12 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Mark Brown" <broonie@...nel.org>
Cc: "Petr Tesarik" <ptesarik@...e.com>,
 "Grant Likely" <grant.likely@...retlab.ca>, linux-kernel@...r.kernel.org,
 linux-spi@...r.kernel.org
Subject: Re: [PATCH] spi: Ensure memory used for spi_write_then_read() is DMA safe

On Fri, Mar 21, 2025, at 15:45, Mark Brown wrote:
> On Fri, Mar 21, 2025 at 01:41:52PM +0100, Arnd Bergmann wrote:
>> On Thu, Mar 20, 2025, at 19:39, Mark Brown wrote:
>
>> which happens in a number of drivers but is harmless as long
>> as the driver doesn't actually try to DMA into that buffer.
>
> Hrm, right.  I think that usage is reasonable so we probably should
> allow it rather than forcing things to do an allocation for a transfer
> that ends up being PIOed anyway almost all the time, OTOH the same API
> is also used for large transfers like firmware downloads where we don't
> want to trigger a spurious copy.  Having different requirements at
> different times would be miserable though so I think we need to just
> accept any buffer and then figure it out inside the API, but I've not
> fully thought that through yet.

My feeling so far is that we want the default regmap interface
to just take any buffer (stack, misaligned, vmalloc, kmap) and
leave it up to the underlying bus to make sure this works in
a sensible way.

Using dma_alloc_noncoherent() should make the implementation
much nicer than GFP_DMA in the past, so we could add a bus
specific helper for SPI that checks if the controller actually
wants to do DMA and whether the buffer is problematic at all,
and then decides to either allocate a bounce buffer and
fill the sg table with the correct DMA address, map the
existing buffer, or pass it without mapping depending on
what the device needs.

      Arnd