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]

Typo, doesn't parallelise build

[tlaurion]

MAKE_JOBS needed, (not MAKE_JOS)

[FckBigTch]

Sorry, no problem i will fix the typo

[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