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.

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
• T480s
• x230
• not working on Novacustom v54 and v56, excluding GBE region PR Staging commits for v540tu/v560tu/ns50/n4x_adl: pr0 patch missing, ME HAP bit, s3, review + unify #1871

Known limitation / open question

Fbwhiptail doesn't support conditionally hiding a single menu entry, so gui-init.sh's show_options_menu is currently duplicated (one version with the MAC randomization entry, one without) selected based on whether the board has the feature enabled.
This works, but duplicating a whole menu function to add one conditional entry doesn't scale well if more optional, board-gated features are added later. An alternative I considered: always show the entry, and if CONFIG_NVMUTIL/CONFIG_IFDTOOL are no on that board, show a message like "This feature is not available on your board" instead of duplicating the menu. That avoids the duplication but surfaces a dead-end option to boards that can never use it. What do you think?

If there are anything changes you'd like me to make, just let me know.

[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)