linux-kernel - Re: r8169: MAC address programmed by coreboot to onboard RTL8111F does not persist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <990a6a3c-bc1e-4b42-b3ae-1ec849d48f5e@molgen.mpg.de>
Date: Thu, 24 Apr 2025 09:09:10 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: netdev@...r.kernel.org, nic_swsd@...ltek.com,
 LKML <linux-kernel@...r.kernel.org>, Keith Hui <buurin@...il.com>
Subject: Re: r8169: MAC address programmed by coreboot to onboard RTL8111F
 does not persist

Dear Heiner,


Thank you for your reply.

Am 22.03.25 um 14:04 schrieb Heiner Kallweit:
> On 22.03.2025 09:50, Paul Menzel wrote:

>> Keith Hui reported the issue *MAC address programmed by coreboot
>> to onboard RTL8111F does not persist* [1] below when using
>> coreboot:
>
> Why do you consider this a bug? IOW: Where is it specified otherwise?

Good question. I do not have the documentation or specification. On 
other boards the current coreboot – a FLOSS firmware – implementation 
worked. coreboot’s driver name is r8168 though, but I guess that is due 
to historical reasons.

>>> I am producing a coreboot port on Asus P8Z77-V LE PLUS on which this
>>> issue is observed. It has a RTL8111F ethernet controller without
>>> EEPROM for vital product data.
>>>
>>> I enabled the rtl8168 driver in coreboot so I can configure the LEDs
>>> and MAC address. Lights work great, but the MAC address always
>>> revert to 00:00:00:00:00:05 by the Linux r8169 kernel module. I
>>> would then have to reassign its proper MAC address using ip link
>>> change eno0 address <mac>.
>
> r8169 in a first place reads the factory-programmed MAC from the chip.
> If this is 00:00:00:00:00:05, then this seems to be an issue with your
> board.
> 
>>> The device appears to be taking the address I programmed, but r8169
>>> reverts it both on init and teardown, insisting that
>>> 00:00:00:00:00:05 is its permanent MAC address.
>>>
>>> Survival of coreboot programmed MAC address before r8169 driver is
>>> confirmed by a debug read back I inserted in the coreboot rtl81xx
>>> driver, as well as by temporarily blacklisting r8169.
>>>
>>> Vendor firmware is unaffected.
>>
> What do you mean with this? What vendor firmware are you referring to?

“vendor firmware” was meant to be the firmware shipped by Asus, that 
comes with the board. coreboot (and the payload) replaces this firmware, 
by flashing the coreboot image to the flash ROM chip.

>> Do you have an idea, where in the Linux driver that happens?
>
> See rtl_init_mac_address() in r8169, and rtl8168_get_mac_address()
> in Realtek's r8168 driver.

Thank you. Keith found a fix for the issue [2]:

> On mainboard/asus/p8z77-v_le_plus, programmed MAC address is being
> reverted with controller resets done at loading and unloading of Linux
> r8169 kernel module.
> 
> Ghidra examination of vendor BIOS reveals an additional sequence to
> program the MAC address into its ERI register block. This patch
> adds code to replicate that sequence, gated by a Kconfig so it's
> only included where necessary.

As stated in the beginning, I do not have have the datasheet, so cannot 
say, if this solution is how it’s supposed to work. (Why program it in 
too places?)

Thank you for you time again, and the pointers.


Kind regards,

Paul


>> [1]: https://ticket.coreboot.org/issues/579#change-2029
[2]: https://review.coreboot.org/c/coreboot/+/87436