Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

[Michael Brown]

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