On 03/04/2025 20:18, Christian Kohlschütter wrote:
+Tom Rini (actually adding Tom to the conversation)
3. When the device is removed, the struct is freed, meaning that a
future malloc() can use that same space.
Yes, that sounds plausible. How can such allocations be prevented?
I assume U-Boot's malloc does not know anything about iPXE's or Linux's
allocation, and vice versa?
iPXE communicates about memory allocation with U-Boot via the EFI memory
allocation API (AllocatePool()/FreePool() and
AllocatePages()/FreePages()). So U-Boot has all the information it
needs to avoid clashing with iPXE, but I have no idea if U-Boot's
malloc() uses the same memory map as U-Boot's implementation of
AllocatePool() et al.
4. DMA traffic could then write over the malloc() region
I'm not seeing where the Ethernet device's stop() is called. The
dwmac_meson8b driver does not have a remove() method, so presumably
DMA is still running after the device is removed. Probably the correct
fix would be to add a remove() method to that driver.
Right. Of course this means that there's still a chance that some future driver
would again fail to do this.
How can we prevent this? Can some removal hook be added automatically upon
registration?
If the dwmac_meson8b driver leaves the hardware in a state where "DMA is
still running after the device is removed", then that is unambiguously a
bug that needs to be fixed.
iPXE's internal (and unrelated) network device API avoids this class of
problem by having the network device removal path automatically ensure
that the network interface is closed:
https://github.com/ipxe/ipxe/blob/7e64e9b6703e6dd363c063d545a5fe63bbc70011/src/net/netdevice.c#L945-L946
There's no hard guarantee that a closed device is quiescent for DMA, but
it happens to be true for most drivers that I've written over the years.
Thanks,
Michael
