GbE-region MAC randomisation

[FckBigTch]

Follow-up to the PoC in #1195. This PR builds on that work and it is a feature to view and randomize the Ethernet MAC address stored in the GbE region of the flash.

Module

• Add nvmutil (from the Libreboot project).

Makefile

• Add ifdtool (from coreboot) as a build target in the Makefile, built directly from the board's coreboot checkout with Heads' existing cross toolchain to coreboot's own module configure step.

initrd/bin/gui-init.sh

• Add a "MAC address randomization" submenu in gui-init.sh, gated on boards config CONFIG_NVMUTIL=y and CONFIG_IFDTOOL=y.

initrd/etc/functions.sh

• Add show_mac
• Add change_mac
• Add clean_up_mac, remove temporary files

initrd/bin/flash.sh

• Adjust CONFIG_FLASH_OPTIONS depending on which function invoked flash.sh

board/

• Add CONFIG_FLASH_TOOL="flashprog --progress --programmer internal"
• Change CONFIG_FLASH_OPTIONS to CONFIG_FLASH_OPTIONS="${CONFIG_FLASH_TOOL} --ifd -i bios -i me -i fd"

GUI

New submenu under the main menu, shown only when both CONFIG_NVMUTIL and CONFIG_IFDTOOL are set to yes for the board:

• Show current Ethernet MAC address
• Randomize Ethernet MAC address (fully random)
• Randomize Ethernet MAC address using a valid OUI (locally-administered/universal OUI pattern, so the result still looks like a plausible vendor-assigned address)

Tested boards

• T480 @FckBigTch
• T480s @FckBigTch
• W530 @Thrilleratplay
• Novacustom v54 and v56 @tlaurion

[tlaurion]

Thanks for picking up on #1195 !

There is ways to make menu options dynamic, thinking of unlocking spi per boot per config settings as an example. Will look deeper in further code review

[tlaurion]

Confused on how ifdtool is built here vs #1195 (which was unclean still, required coreboot's built ifdtool that is needed to build coreboot (see modules/coreboot there) to add Makefile hacks to pack ifdtool as cbmem is packed to be used inside of Heads.

ifdtool needs to be built with musl-cross-make to depend on musl's libc; so unclear how building it with coreboot's buildstack produces an actual working ifdtool to be used inside of heads? You tested this pr @FckBigTch ?

[FckBigTch]

Confused on how ifdtool is built here vs #1195 (which was unclean still, required coreboot's built ifdtool that is needed to build coreboot (see modules/coreboot there) to add Makefile hacks to pack ifdtool as cbmem is packed to be used inside of Heads.

ifdtool needs to be built with musl-cross-make to depend on musl's libc; so unclear how building it with coreboot's buildstack produces an actual working ifdtool to be used inside of heads? You tested this pr @FckBigTch ?

Yes, I've tested several times, and flashed the resulting ROMs on t480s, t480 and x230. Ifdtool is usable inside of heads.
I just tried to do it like cbmem, superiotool or inteltool.
ifdtool is built from '$(build)/$(coreboot_dir)/util/ifdtool' using the board's own coreboot source tree, musl-cross-make and the board's DOTCONFIG, rather than duplicating the source tree.

Confirmed it's actually musl:

file build/x86/coreboot-25.09/util/ifdtool/ifdtool
build/x86/coreboot-25.09/util/ifdtool/ifdtool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped

Interpreter is /lib/ld-musl-x86_64.so.1

[tlaurion]

Some notes from deeper review

• why we say it doesn't work with v540tu/v560tu? from a point of view of board config (flash command) v540tu/v560tu do the right thing here: they exclude for future internal flash the GBE region by specifying flash regions that are intended to be flashed only (desired, otherwise an internal upgrade would replace GBE with hardcoded mac) : export CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd"
  • Actually, by merging this PR, all boards that can have their mac address changed should have that flash command changed to exclude GBE from flashing from internal upgrades, otherwise replacing it in internal flashing of new rom ( right now : export CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal" so overwriting the whole flash )
  • What is missing in this PR is now a distinction for overriding temporarily (at runtime only) of the GBE region when flashing that section only with flashtool export from board config so changing GBE would only be done explicitly when the user wants to override its mac from config menu options, no? export CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd -i gbe"
• Still missing: dynamic menu option.
• Interesting gain here with ifdtool packed in, we could (other PR, not here) extract MRC cache and inject it in the rom so that memory training happens only if not matching (flashing rom with current commands overwirte the memory training cache, resulting in long boot times after flash for all DDR4, DDR5 taking up to near a minute before raminit is finished, which is the part drawing bootsplash on screen, leaving user in the dark up to that point.)

Will think about that a bit more. If you have ideas let me know @FckBigTch

[FckBigTch]

Some notes from deeper review

* why we say it doesn't work with v540tu/v560tu? from a point of view of board config (flash command) v540tu/v560tu do the right thing here: they exclude for future internal flash the GBE region by specifying flash regions that are intended to be flashed only (desired, otherwise an internal upgrade would replace GBE with hardcoded mac) :  `export CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd"`
  
  * Actually, by merging this PR, all boards that can have their mac address changed should have that flash command changed to exclude GBE from flashing from internal upgrades, otherwise replacing it in internal flashing of new rom ( right now : `export CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal"` so overwriting the whole flash )
  * What is missing in this PR is now a distinction for overriding temporarily (at runtime only) of the GBE region when flashing that section only with flashtool export from board config so changing GBE would only be done explicitly when the user wants to override its mac from config menu options, no? `export CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd -i gbe"`

* Still missing: dynamic menu option.

* Interesting gain here with ifdtool packed in, we could (other PR, not here) extract MRC cache and inject it in the rom so that memory training happens only if not matching (flashing rom with current commands overwirte the memory training cache, resulting in long boot times after flash for all DDR4, DDR5 taking up to near a minute before raminit is finished, which is the part drawing bootsplash on screen, leaving user in the dark up to that point.)

Will think about that a bit more. If you have ideas let me know @FckBigTch

The reason I thought the Novacustom models should be excluded is that the config explicitly states:
"NovaCustom V54 MTL (integrated graphics) board configuration
Note the FLASH_OPTIONS: '--ifd -i bios -i me -i fd'
This excludes gbe from internal flashing, otherwise mac address would revert to '88:88:88:88:87:88' see #1871 (comment)
Same options should be used when externally flashing the first time, otherwise Intel GbE region (Ethernet config blob) will be overwritten and MAC reverted to '88:88:88:88:87:88'.”

That means it's not possible to generate a random MAC address, right? But I understand that overwriting the GBE region should be avoided during an update.

I hadn't even thought of the idea with the dynamic menu. I'll follow your advice and try to implement it.

[tlaurion]

The reason I thought the Novacustom models should be excluded is that the config explicitly states:
"NovaCustom V54 MTL (integrated graphics) board configuration
Note the FLASH_OPTIONS: '--ifd -i bios -i me -i fd'
This excludes gbe from internal flashing, otherwise mac address would revert to '88:88:88:88:87:88' see #1871 (comment)
Same options should be used when externally flashing the first time, otherwise Intel GbE region (Ethernet config blob) will be overwritten and MAC reverted to '88:88:88:88:87:88'.”

That means it's not possible to generate a random MAC address, right? But I understand that overwriting the GBE region should be avoided during an update.

Misunderstanding. This means those boards pack a GBE (see coreboot configs) but don't ever flash it per initial flashing instructions or internal flashing. If someone misread initial flashing (which is done by OEM not end users in the case of these boards), then MAC address would become generic as per packed in rom GBE.

I hadn't even thought of the idea with the dynamic menu. I'll follow your advice and try to implement it.

[tlaurion]

The reason I thought the Novacustom models should be excluded is that the config explicitly states:
"NovaCustom V54 MTL (integrated graphics) board configuration
Note the FLASH_OPTIONS: '--ifd -i bios -i me -i fd'
This excludes gbe from internal flashing, otherwise mac address would revert to '88:88:88:88:87:88' see #1871 (comment)
Same options should be used when externally flashing the first time, otherwise Intel GbE region (Ethernet config blob) will be overwritten and MAC reverted to '88:88:88:88:87:88'.”

That means it's not possible to generate a random MAC address, right? But I understand that overwriting the GBE region should be avoided during an update.

Misunderstanding. This means those boards pack a GBE (see coreboot configs) but don't ever flash it per initial flashing instructions or internal flashing. If someone misread initial flashing (which is done by OEM not end users in the case of these boards), then MAC address would become generic as per packed in rom GBE.

Also see linuxboot/heads-wiki#209 (needed)

[FckBigTch]

I've revised the menu now. Instead of duplicating the whole function for the gated/non-gated case, the menu items are now built into a bash array, with the MAC randomization entry conditionally appended only when CONFIG_NVMUTIL=y and CONFIG_IFDTOOL=y.

[tlaurion]

Took a little time to think about linuxboot/heads-wiki#209 and current widespread

• CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal"

It seems that the proper usage pattern would become, in all boards having GBE

• CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd" as v540tu/v560tu
• And then, when calling flash.sh for GBE persistence when MAC randomized, save current CONFIG_FLASH_OPTION to BACKUP_FLASH_OPTION (BACKUP_FLASH_OPTION=CONFIG_FLASH_OPTION), append GBE region for current flash op (CONFIG_FLASH_OPTION+=" -i gbe"), flash, and then restore CONFIG_FLASH_OPTION=BACKUP_FLASH_OPTION).

Thoughts @FckBigTch ?

[tlaurion]

The reason I thought the Novacustom models should be excluded is that the config explicitly states:
"NovaCustom V54 MTL (integrated graphics) board configuration
Note the FLASH_OPTIONS: '--ifd -i bios -i me -i fd'
This excludes gbe from internal flashing, otherwise mac address would revert to '88:88:88:88:87:88' see #1871 (comment)
Same options should be used when externally flashing the first time, otherwise Intel GbE region (Ethernet config blob) will be overwritten and MAC reverted to '88:88:88:88:87:88'.”
That means it's not possible to generate a random MAC address, right? But I understand that overwriting the GBE region should be avoided during an update.

Misunderstanding. This means those boards pack a GBE (see coreboot configs) but don't ever flash it per initial flashing instructions or internal flashing. If someone misread initial flashing (which is done by OEM not end users in the case of these boards), then MAC address would become generic as per packed in rom GBE.

I hadn't even thought of the idea with the dynamic menu. I'll follow your advice and try to implement it.

Sorry i misled you @FckBigTch

grep -Ri gbe config/coreboot-* | grep nova
config/coreboot-novacustom-v540tu.config:CONFIG_MAINBOARD_USES_IFD_GBE_REGION=y
config/coreboot-novacustom-v540tu.config:# CONFIG_HAVE_GBE_BIN is not set
config/coreboot-novacustom-v560tu.config:CONFIG_MAINBOARD_USES_IFD_GBE_REGION=y
config/coreboot-novacustom-v560tu.config:# CONFIG_HAVE_GBE_BIN is not set

So, what that means is that the SPI chip HAS a GBE, but shipped ROM images don't and keep OEM's.
So. with IFDTOOL, we can get OEM unique GBE, modify it, flash it back.
The old "maximized" builds mindset was to put all required blobs (including config ones), where novacustom's took a different direction, which is arguably good but changed philosiphy as pointed in old heads-wiki doc so that initial flashing, and internal flashing, do not touch the region. Prior attempts to not pack GBE under x230 resulted in GBE not working correctly (we were overwritting GBE region by flashing whole SPI without one!), as well as current m900 workstation community effort not having working Ethernet, which i didn't investigate yet: but the m900 flashes with a backed GBE which for unknown reasons don't work.

So TLDR: We should have all boards having GBE only write to specific IFD's regions, not touching GBE even if one is provided by rom (excluding GBE from flashprog). And have GBE flashed when user intends it (when one is generated from nvmutil in this PR), where internal upgrade don't touch it unless expressively asked for. Makes sense?

Outside of v540tu/v560tu not having GBE in packed ROM; Others have it:

user@debian-13:~/heads-clean2$ grep -Ri "CONFIG_HAVE_GBE_BIN=y" config/coreboot-* | grep "\.config:"
config/coreboot-m900-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-optiplex-7019_9010-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-optiplex-7019_9010_TXT-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t420.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t420-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t430-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t440p.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t480-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t480s-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t520-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t530-dgpu-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t530-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w530-dgpu-K1000m-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w530-dgpu-K2000m-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w530-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w541.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x220.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x220-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x230-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x230-maximized-fhd_edp.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-z220-cmt.config:CONFIG_HAVE_GBE_BIN=y

Makes sense?

[FckBigTch]

Took a little time to think about linuxboot/heads-wiki#209 and current widespread

* `CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal"`

It seems that the proper usage pattern would become, in all boards having GBE

* `CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd"` as v540tu/v560tu

* And then, when calling flash.sh for GBE persistence when MAC randomized, save current CONFIG_FLASH_OPTION to BACKUP_FLASH_OPTION  (BACKUP_FLASH_OPTION=CONFIG_FLASH_OPTION), append GBE region for current flash op (CONFIG_FLASH_OPTION+="  -i gbe"), flash, and then restore CONFIG_FLASH_OPTION=BACKUP_FLASH_OPTION).

Thoughts @FckBigTch ?

I'm sorry for the late reply, but I had to think about what you wrote.
I’m still confused, not sure understanding you correctly.
Makes sense to me, defaulting all GBE-capable boards to exclude GBE from normal flash/update operations.
What I do not understand, why do you want to backup CONFIG_FLASH_OPTIONS?
You’re not just talking about MAC-randomization, but about flashing the gbe in general during an update or reflash?

If the user or whoever first did the (external) flash overwrote the GBE, so it’s DE:AD:CO:FF:EE. If they use the randomization feature, they get a random MAC. If all boards exclude GBE (CONFIG_FLASH_OPTIONS change), the random mac is persistent during an update.
Do you want to give the user the option to have the GBE overwritten again during an update or reflash so that they get DE:AD:CO:FF:EE back?

I'm not sure if that's really necessary, but I understand that you want to offer an easy way to revert to the default settings.

[FckBigTch]

The reason I thought the Novacustom models should be excluded is that the config explicitly states:
"NovaCustom V54 MTL (integrated graphics) board configuration
Note the FLASH_OPTIONS: '--ifd -i bios -i me -i fd'
This excludes gbe from internal flashing, otherwise mac address would revert to '88:88:88:88:87:88' see #1871 (comment)
Same options should be used when externally flashing the first time, otherwise Intel GbE region (Ethernet config blob) will be overwritten and MAC reverted to '88:88:88:88:87:88'.”
That means it's not possible to generate a random MAC address, right? But I understand that overwriting the GBE region should be avoided during an update.

Misunderstanding. This means those boards pack a GBE (see coreboot configs) but don't ever flash it per initial flashing instructions or internal flashing. If someone misread initial flashing (which is done by OEM not end users in the case of these boards), then MAC address would become generic as per packed in rom GBE.

I hadn't even thought of the idea with the dynamic menu. I'll follow your advice and try to implement it.

Sorry i misled you @FckBigTch

grep -Ri gbe config/coreboot-* | grep nova
config/coreboot-novacustom-v540tu.config:CONFIG_MAINBOARD_USES_IFD_GBE_REGION=y
config/coreboot-novacustom-v540tu.config:# CONFIG_HAVE_GBE_BIN is not set
config/coreboot-novacustom-v560tu.config:CONFIG_MAINBOARD_USES_IFD_GBE_REGION=y
config/coreboot-novacustom-v560tu.config:# CONFIG_HAVE_GBE_BIN is not set

So, what that means is that the SPI chip HAS a GBE, but shipped ROM images don't and keep OEM's. So. with IFDTOOL, we can get OEM unique GBE, modify it, flash it back. The old "maximized" builds mindset was to put all required blobs (including config ones), where novacustom's took a different direction, which is arguably good but changed philosiphy as pointed in old heads-wiki doc so that initial flashing, and internal flashing, do not touch the region. Prior attempts to not pack GBE under x230 resulted in GBE not working correctly (we were overwritting GBE region by flashing whole SPI without one!), as well as current m900 workstation community effort not having working Ethernet, which i didn't investigate yet: but the m900 flashes with a backed GBE which for unknown reasons don't work.

So TLDR: We should have all boards having GBE only write to specific IFD's regions, not touching GBE even if one is provided by rom (excluding GBE from flashprog). And have GBE flashed when user intends it (when one is generated from nvmutil in this PR), where internal upgrade don't touch it unless expressively asked for. Makes sense?

Outside of v540tu/v560tu not having GBE in packed ROM; Others have it:

user@debian-13:~/heads-clean2$ grep -Ri "CONFIG_HAVE_GBE_BIN=y" config/coreboot-* | grep "\.config:"
config/coreboot-m900-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-optiplex-7019_9010-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-optiplex-7019_9010_TXT-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t420.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t420-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t430-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t440p.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t480-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t480s-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t520-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t530-dgpu-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-t530-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w530-dgpu-K1000m-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w530-dgpu-K2000m-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w530-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-w541.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x220.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x220-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x230-maximized.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-x230-maximized-fhd_edp.config:CONFIG_HAVE_GBE_BIN=y
config/coreboot-z220-cmt.config:CONFIG_HAVE_GBE_BIN=y

Makes sense?

So, is there anything else you'd like me to do?
I can make the changes to CONFIG_FLASH_OPTIONS for all relevant boards like this
CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd

[tlaurion]

Took a little time to think about linuxboot/heads-wiki#209 and current widespread

* `CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal"`

It seems that the proper usage pattern would become, in all boards having GBE

* `CONFIG_FLASH_OPTIONS="flashprog --progress --programmer internal --ifd -i bios -i me -i fd"` as v540tu/v560tu

* And then, when calling flash.sh for GBE persistence when MAC randomized, save current CONFIG_FLASH_OPTION to BACKUP_FLASH_OPTION  (BACKUP_FLASH_OPTION=CONFIG_FLASH_OPTION), append GBE region for current flash op (CONFIG_FLASH_OPTION+="  -i gbe"), flash, and then restore CONFIG_FLASH_OPTION=BACKUP_FLASH_OPTION).

Thoughts @FckBigTch ?

I'm sorry for the late reply, but I had to think about what you wrote. I’m still confused, not sure understanding you correctly. Makes sense to me, defaulting all GBE-capable boards to exclude GBE from normal flash/update operations. What I do not understand, why do you want to backup CONFIG_FLASH_OPTIONS? You’re not just talking about MAC-randomization, but about flashing the gbe in general during an update or reflash?

If the user or whoever first did the (external) flash overwrote the GBE, so it’s DE:AD:CO:FF:EE. If they use the randomization feature, they get a random MAC. If all boards exclude GBE (CONFIG_FLASH_OPTIONS change), the random mac is persistent during an update. Do you want to give the user the option to have the GBE overwritten again during an update or reflash so that they get DE:AD:CO:FF:EE back?

I'm not sure if that's really necessary, but I understand that you want to offer an easy way to revert to the default settings.

Sorry for having confused you. I checked the changes, and now I understand why the misunderstandings.
Everywhere in codebase, flashing operations use flash.sh wrapper which in turn uses CONFIG_FLASH_OPTIONS; you call flashprog directly. This is not a good pattern since if/when flashrom will have proper --progress support to inform use of progress of flashing operations, we might switch back to flashrom and calling the packed programmer directly is not what the codebase do without verifying its existence. flash.sh and CONFIG_FLASH_OPTIONS are used everywhere in codebase for that reason.

Once this is CONFIG_FLASH_OPTIONS and flash.sh used, why I wanted to keep prior CONFIG_FLASH_OPTIONS to restore it before returning to prior operations is exposed, otherwise a reboot.sh would be needed (also normal pattern after a flash. We might need to simply add in all boards CONFIG_FLASH_TOOL="flashprog" and CONFIG_FLASH_OPTIONS=$CONFIG_FLASH_TOOL --programmer....." so that you could use CONFIG_FLASH directly if that is the path you prefer without needing backup of previous board, extract the programmer to call only --ifd -i gbe... That's where I was going to.

gui-init.sh should not have additional functions, it should either be in functions.sh or gui_functions.sh that gui-init.sh sources. One cannot cd into /tmp in one function and not change back to prior location either since other heads workflows will break, unless a reboot is done too there. Some of your added functions do not check for ifdtool or nvutil presence (not guarded) which might also cause issues down the line which we try to not have to deal with.

Sorry I wasn't clear enough; I didn't see you were calling flashprog directly in added functions under gui-init.sh

[FckBigTch]

Make sense! Thanks for your patience and explanations. I will make the changes.

[FckBigTch]

I've made the changes. I set the t420 and x220 to "no" in the Tools section of the config because of the space issue (7 MB). I'm not sure if the new CONFIG_FLASH_OPTIONS still make sense for these boards. Maybe it would be better to stick with the old version without options after all?

[tlaurion]

I've made the changes. I set the t420 and x220 to "no" in the Tools section of the config because of the space issue (7 MB). I'm not sure if the new CONFIG_FLASH_OPTIONS still make sense for these boards. Maybe it would be better to stick with the old version without options after all?

yes, it should be unified everywhere (all boards) so we can clearly say in heads-wiki that we did a philosophical stance change; the user is left with a choice, per our discussions here, to flash externally with or without board's rom GBE, or, to keep the one that was fused in config per OEM/ODM. If we do so, the same general guidelines will be possible for all boards under https://osresearch.net/Flashing-guides (and we will be able to get rid of all those different flashing instructions which are basically duplicates with a generic "FLASHTOOL --progress --programmer XYZ [--chip ZYX] --ifd -i bios -i me -i fd" where user is invited to check for external programmer choice quirks without having to repeat ourselves.

Makes sense?

[tlaurion]

I really think we need to distinguish/reuse FLASHTOOL/FLASH_OPTIONS to only flash gbe when needed, not touching anything else.

[NobodyNo0ne]

Heads shows the MAC address as having changed afterwards.
Seems to work? If images/ test inside booted OS is preferred, will do.

Rebooting and showing MAC from heads once gbe flashed, and booting and checking MAC should be the same, as would be going to recovery shell and calling https://github.com/linuxboot/heads/blob/master/initrd/bin/network-init-recovery.sh with rj45 cable plugged in to a functional router (ifconfig call there at end of the script after network drivers loaded). After all, this PR is about adding tooling to generate and replacing gbe.bin which contains MAC address for intel ethernet, thanks to Leah's work.

That was confirmed on my side on v540tu and v560tu.

No RJ45 slot, done via USB-C Thunderbolt. I do not have the dongle.

[tlaurion]

Heads shows the MAC address as having changed afterwards.
Seems to work? If images/ test inside booted OS is preferred, will do.

Rebooting and showing MAC from heads once gbe flashed, and booting and checking MAC should be the same, as would be going to recovery shell and calling https://github.com/linuxboot/heads/blob/master/initrd/bin/network-init-recovery.sh with rj45 cable plugged in to a functional router (ifconfig call there at end of the script after network drivers loaded). After all, this PR is about adding tooling to generate and replacing gbe.bin which contains MAC address for intel ethernet, thanks to Leah's work.

That was confirmed on my side on v540tu and v560tu.

No RJ45 slot, done via USB-C Thunderbolt. I do not have the dongle.

Verified from docs : The X280’s Intel I219 Ethernet is a native PCIe device reached only through the proprietary side mini-port + Gen 2 adapter and has nothing to do with the Thunderbolt 3 controller, and managed by the linux e1000e kernel module.

@NobodyNo0ne seems like the docs for X280 would benefit from those facts for everyone's benefit.

[NobodyNo0ne]

No RJ45 slot, done via USB-C Thunderbolt. I do not have the dongle.

Verified from docs : The X280’s Intel I219 Ethernet is a native PCIe device reached only through the proprietary side mini-port + Gen 2 adapter and has nothing to do with the Thunderbolt 3 controller, and managed by the linux e1000e kernel module.

@NobodyNo0ne seems like the docs for X280 would benefit from those facts for everyone's benefit.

should I open another issue/pr for the wiki to include it as an additional note? Not sure if I should put it in the flashing guide though.
No general page for devices, and that seems a bit much anyway. May be worth just linking to a page outside the wiki for such things?

I think the wiki itself is fine. It relates to Heads specifically.

I will need to get the dongle then.

[tlaurion]

No RJ45 slot, done via USB-C Thunderbolt. I do not have the dongle.

Verified from docs : The X280’s Intel I219 Ethernet is a native PCIe device reached only through the proprietary side mini-port + Gen 2 adapter and has nothing to do with the Thunderbolt 3 controller, and managed by the linux e1000e kernel module.
@NobodyNo0ne seems like the docs for X280 would benefit from those facts for everyone's benefit.

should I open another issue/pr for the wiki to include it as an additional note? Not sure if I should put it in the flashing guide though. No general page for devices, and that seems a bit much anyway. May be worth just linking to a page outside the wiki for such things?

I think the wiki itself is fine. It relates to Heads specifically.

I will need to get the dongle then.

No comment, if you are willing to restructure the whole wiki pages go for it. To be honest, when I arrive to a documentation place and I see a search button, I would search for x280 and if i see there a Specs page, I would click on it. I see no point duplicating even more the docs, but I welcome suggestions. I'm not a documentarist.

I only commented here because x280 doesn't require thunderbolt/usb3 drivers to activate e1000e which is intel ethernet through pci as any other board, lenovo just decided that x280 owners will need to buy an adapter to use their ethernet port. Just corrected the facts: there is no such thunderbolt ethernet adapter required, so Heads configs for x280 is ok and this PR works on x280 as well from GBE config blob perspective read/written.
And if there was confusion on thunderbolt, it might happen again and I will not repeat myself but pointing to docs, ideally. As of board status across all boards, x280 seems to be the only one requiring adapter, so I felt it needed clarifications but yet again, nothing Heads related here and users wanting ethernet will look at x280 specs, this is not Heads related in the sense that if ethernet works on OS, ethernet works under Heads, so not a Heads problem to document either, but that's my perspective.

TLDR: I would add a note under https://osresearch.net/X280-maximized-flashing; Heads doesn't plan to document the world. Heads is concerned about drivers (e1000e provided as module) and here, GBE, and if the adapter, plugging rj45 cable in adapter would make Heads work optional network recovery get an IP.
MAC address showed by this PR addition works but cannot be tested. That's good enough for Heads.

[NobodyNo0ne]

No comment, if you are willing to restructure the whole wiki pages go for it. To be honest, when I arrive to a documentation place and I see a search button, I would search for x280 and if i see there a Specs page, I would click on it. I see no point duplicating even more the docs, but I welcome suggestions. I'm not a documentarist.

I only commented here because x280 doesn't require thunderbolt/usb3 drivers to activate e1000e which is intel ethernet through pci as any other board, lenovo just decided that x280 owners will need to buy an adapter to use their ethernet port. Just corrected the facts: there is no such thunderbolt ethernet adapter required, so Heads configs for x280 is ok and this PR works on x280 as well from GBE config blob perspective read/written. And if there was confusion on thunderbolt, it might happen again and I will not repeat myself but pointing to docs, ideally. As of board status across all boards, x280 seems to be the only one requiring adapter, so I felt it needed clarifications but yet again, nothing Heads related here and users wanting ethernet will look at x280 specs, this is not Heads related in the sense that if ethernet works on OS, ethernet works under Heads, so not a Heads problem to document either, but that's my perspective.

TLDR: I would add a note under https://osresearch.net/X280-maximized-flashing; Heads doesn't plan to document the world. Heads is concerned about drivers (e1000e provided as module) and here, GBE, and if the adapter, plugging rj45 cable in adapter would make Heads work optional network recovery get an IP. MAC address showed by this PR addition works but cannot be tested. That's good enough for Heads.

I did not know the ethernet worked that way, so I learnt something there myself.
I'm not one for documentation either to be fair.

I figured the ethernet worked a bit differently from whatever Lenovo actually decided to do (given it is ALSO the thunderbolt port)

Still not sure why they did it that way. Form-over-Function at a guess. <- I need to get a proper pogo-stick probe for the smaller thunderbolt chip anyway, its too fiddly to get one of my clips on it. I'll add that adapter to that shopping list.

Still, the MAC address at least appears to change, and persist after a reboot.

[FckBigTch]

I can confirm changing and randomizing ethernet mac address works for the T480 and T480s.
Are we done?
Anything else?

[NobodyNo0ne]

I can confirm changing and randomizing ethernet mac address works for the T480 and T480s.

Nice!

Are we done?

You should be, but I still do not have an ethernet dongle, and am moving tomorrow, so will probably be MIA a day or two. Unless TLaurion has requests.

Sorry about my end. I've ordered the stuff in advance to where I am moving. Hopefully not too long?

[FckBigTch]

I can confirm changing and randomizing ethernet mac address works for the T480 and T480s.

Nice!

Are we done?

You should be, but I still do not have an ethernet dongle, and am moving tomorrow, so will probably be MIA a day or two. Unless TLaurion has requests.

Yeah, exactly. I just wanted to know if there's anything else to do.

Sorry about my end. I've ordered the stuff in advance to where I am moving. Hopefully not too long?

no pressure

[tlaurion]

@FckBigTch I asked for testing/comments under matrix channel

Please update OP to fit content. Ideally add screenshots :)

[tlaurion]

Kano was merged. If you beat me to add, adding the same sperarion of flash prog and flash options to all boards would be necessary before merge.

[tlaurion]

@FckBigTch I asked for testing/comments under matrix channel

Please update OP to fit content. Ideally add screenshots :)

Have you checked the matrix thread?

[Thrilleratplay]

Tested on a W530. LGTM

[tlaurion]

There is no reason waiting longer. Let's keep an eye open on bug reports and have that merged. Asking copilot for review one last time

[Copilot]

🟡 Changes recommended

Unhandled nvmutil failures, unsafe globally administered random addresses, and unsupported Kano enablement must be corrected.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 40/42 changed files
• Comments generated: 5
• Review effort level: Balanced

[Copilot]

🟡 Changes recommended

Duplicate nvm invocations still mutate or read the GbE image before the checked calls, and the current-MAC dialog is shown before validating that a MAC was parsed.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 40/42 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[tlaurion]

LGTM let's see if copilot has something relevant for final review

[FckBigTch]

I got my hopes up too soon, careless mistake. Now it should be fine