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

[Simon Glass]

+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.

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.

Regards,
Simon