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

[Christian Kohlschütter]

+Tom Rini (actually adding Tom to the conversation)

> On 3. Apr 2025, at 19:54, Simon Glass <sjg at chromium.org> wrote:
> 
> +Tom Rini in case this affects the release
> 
> Hi Christian,
> 
> On Fri, 4 Apr 2025 at 01:46, Christian Kohlschütter
> <christian at kohlschutter.com> wrote:
>> 
>> Hi Simon,
>> 
>>> On 1. Apr 2025, at 17:51, Simon Glass <sjg at chromium.org> wrote:
>>>> 
>>>> but I don't know precisely what these various functions are supposed to
>>>> do, and I can't find any path that leads from any of these to eth_halt().
>>>> 
>>>> Is it possible that U-Boot is failing to call eth_halt() in response to
>>>> ExitBootServices(), and is therefore leaving the network device active
>>>> and performing DMA while the kernel starts up?
>>> 
>>> The dm_remove_devices_active() is supposed to handle this, but it is
>>> possible that one of the drivers lacks a remove() method.
>> 
>> for what it's worth, this is happening on both ODROID N2+ (meson8b-dwmac) as well as NanoPI R4S (rk_gmac-dwmac).
>> 
>> I also don't understand why reverting 06ef8089f876b6dabf56caba31a05c003f03c629 "fixes" this behavior. Does it mean that any memalign / malloc may cause this?
>> Also, how can this failure mode be detected and prevented in code?
>> 
>> I really don't fancy the thought of remote code injection into Linux initrd by spoofing Ethernet packages, but it really looks like a possibility.
> 
> Here's my idea of what might be going on based on Michael's observations:
> 
> 1. designware_eth_start() starts the interface and
> designware_eth_stop() stops it
> 
> 2. tx_descs_init() sets up the DMA and uses the device-private info
> (struct dw_eth_dev)
> 
> 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?

> 
> 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?

> 
> Regards,
> Simon

Thanks for looking into this!
Christian