A security fix briefly breaks DMA

Posted Apr 2, 2022 19:55 UTC (Sat) by iabervon (subscriber, #722)
Parent article: A security fix briefly breaks DMA

I don't see how the bounce buffer copy and the ongoing DMA avoid interacting in such a way that a_packet_is_ready() can return true when not all of the packet was in the bounce buffer in time to get copied out. It seems like you'd need a sync operation that let you specify the order that the bounce buffer is read in a way that wouldn't be optimal for a sync operation that was only reliable if the device was no longer writing when you called it.

A security fix briefly breaks DMA

Posted Apr 3, 2022 8:36 UTC (Sun) by farnz (subscriber, #17727) [Link]

In the bounce buffer case, it can't. But on a lot of systems, especially those in WiFi APs, the DMA is happening into the CPU buffer directly (no bounce buffer), and there it's an optimization to say "hey, packet copied in, resync and continue".

A security fix briefly breaks DMA

Posted Apr 3, 2022 8:54 UTC (Sun) by dvrabel (subscriber, #9500) [Link] (1 responses)

The device writes the status word (with its RxDone bit) _after_ writing the packet and other metadata. Thus, if the CPU sees RxDone it knows all the other data has been written.

A security fix briefly breaks DMA

Posted Apr 3, 2022 17:40 UTC (Sun) by iabervon (subscriber, #722) [Link]

That's what I thought, but how does the CPU know that none of the sync happened before the status word was written, with the copy of the status word happening after it was written? You'd need to make sure that the first thing that gets copied during the sync is the status word, and I'm not finding any documentation that the sync happens in any particular order.

I expect that the copy actually happens from low to high, and the status word is at the beginning, so it always works, but relies on a property of the core API that was never promised.