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

[Michael Brown]

On 03/04/2025 23:41, Simon Glass wrote:
> On Fri, 4 Apr 2025 at 08:18, Christian Kohlschütter
> <christian at kohlschutter.com> wrote:
>>> On 3. Apr 2025, at 19:54, Simon Glass <sjg at chromium.org> wrote:
>>>
>>> 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?
> 
> Visual inspection of each network driver should help.
> 
> I'm not sure if we want to 'stop' all the network devices before
> booting Linux, but perhaps we could perhaps provide that feature as a
> Kconfig option, e.g. in announce_and_cleanup(), which could really use
> a cleanup to make it common across archs.

If the memory used for network device DMA is not reserved to prevent use 
by the operating system, then you absolutely need to stop all network 
devices.  Otherwise, what is there that prevents random parts of the OS 
kernel or data from being overwritten by received packets?

In the UEFI model, the point at which ExitBootServices() returns 
successfully is the point that any memory marked as EfiBootServicesCode 
or EfiBootServicesData becomes usable as general-purpose RAM by the OS. 
The firmware (including any DMA-capable devices configured by the 
firmware) is not permitted to continue to write to this memory after 
this point.

Thanks,

Michael