Well.

@Thrilleratplay my change for mac randomization was intended to be written under https://github.com/osresearch/heads/blob/master/initrd/bin/network-init-recovery to be called when needed, while automatizing mac randomization to reuse Intel Ethernet OUI identifier and randomize the rest, for internal Heads use only. (Emergency restore of wyng-backups from network, Complete disk reconstruction from latest remote wyng-backups, download and verify ROM content against same git commit hashes.txt online... those sort of things)

As you noticed, we are offloading the task of mac randomization/setting MAC permanently to the OS. Since we faked ethernet mac address permanently in ROM. The only foreseen problem with that, seriously, is to have many xx30-maximized xx20-maximized ROM based laptops in the current ethernet LAN, having the same unchanged MAC which would cause routing problems and conflict on local network, where first device will have link, where subsequent connected machines wouldn't.

Otherwise there is no real impact. In your use case, that would be wifi based mostly (no?), which is not having impact from this change. For Ethernet based connections, it goes with below documentation (generalisable to all NetworkManager based OSes). Otherwise the user is claiming loud and high (for NAC solutions, macauth) that he is using libreboot/heads based rom from the MAC address alone. Tracking devices by mac address alone is a real problem where MAC address randomization should be enforced for all privacy conscious anyway, and should be implemented by default in all OSes.

Under QubesOS, this is suggested. If connecting to wifi/ethernet with a MAC address that you need consistent/persistent/permanent, you will have to change that network profile parameter to set that MAC address to be permanent for that network profile. The good news is that first connection will be randomized, and the user can then set the SSID profile to not ever change mac address again, setting that profile to permanent. The same applies to ehternet profiles, where one needs to be created per network connection location, for example, where the basic one should randomize by default. That requires the configuration changes explained in QubesOS post for recent NetworkManager.

In your use case, where you want that MAC to be copied from the original, the use case is to have those blobs extracted from backup by the extract.sh equivalent so that gbe.bin is conserved. Otherwise, the download script currently uses the fixated MAC from binutil outputted under gbe.bin while downloading and neutering ME and exporting me_cleaner generated ifd.bin.

TL;DR version directly addressing your points:

Should be a togglable feature, turned off by default. Some networks, such as university campuses, require MAC addresses to be registered to access a network. or have a limit of devices associated to an account.

That mac randomization would impact only local OS: Heads. When kexec'ing, the OS will reset to hardcoded MAC.
Solution to that could be to permit calling the script with mac address passed as argument. But I see limited interest/impact here for Heads use case alone.

MAC address and checksum much be updated if rewriting the GBE partition.

That would be to be updated in the download script if desired, where changing it would not produce totally reproducible ROMs.

@Thrilleratplay : Thoughts?

@tlaurion Oh, that is much simpler than what I though was planned. My comments are moot.

Needs rando. Sorry will point at PR when done

I would like to see OS-Independent MAC randomizing. There are always situations where you would like to for example boot a generic linux-iso from usb and dont have preconfigured MAC randomizing and maybe the linux-iso dont have macchanger preinstalled.

I would like to see OS-Independent MAC randomizing. There are always situations where you would like to for example boot a generic linux-iso from usb and dont have preconfigured MAC randomizing and maybe the linux-iso dont have macchanger preinstalled.

@fhvyhjriur while interesting, this would requoire Heads internal reflashing of the GBE region with Heads specific tools that would play with the IGB file. I think @Thrilleratplay wanted to do something about it, but i'm not sure he thought of doing it in shell scripts :P

@tlaurion My original thought was to store a binary patch containing the original or desired MAC in the ROM like the GPG key, then apply it during the internal flash process. This, setting a specific random MAC could likely be done with a simple program written in C. The only thing that needs to change is the MAC and checksum.

Changing the mac address

By default, the builds on this website use the generic mac address used by ich9gen, however it is completely possible to change the mac address WITHOUT recompiling or using hardware flashing. Here are the steps necessary to modify the rom with the new mac address. Keep in mind that ? represents the size of the rom chip, and switching to the microcode repository is done by replacing roms/free by roms/microcode in the cp command:

1. git clone https://github.com/JaGoLi/Libreboot-X200-Updated.git libreboot-x200 && cd libreboot-x200
2. ./ich9gen --macaddress XX:XX:XX:XX:XX:XX
3. cp roms/free/x200_?mb_FREE.rom x200.rom
4. dd if=ich9fdgbe_?mb.bin of=x200.rom bs=12k count=1 conv=notrunc

Src https://github.com/JaGoLi/Libreboot-X200-Updated

ich9gen is a dead project. Its a waste of time to use it for todays projects. Today the GBE can also be created by using the official coreboot tool named bincfg : https://github.com/coreboot/coreboot/blob/master/util/bincfg/Makefile#L15

@fhvyhjriur the gbe.bin was createfd by bincfg. The goal here would be to change mac address. borrowing working code and credit accordingly. @Thrilleratplay .

Does someone know if it would be possible to add the mac addres into the nvram and link the GBE-mac-reading-part to there? This could be the halfway-solution because it would make it more easy to read and modify the mac-address out of the OS, out of coreboot(addon?) and out of for example GRUB(yes, grub can modify nvram settings).

@fhvyhjriur No, nvram configuration only pertains to the BIOS region. The GBE region is completely separate.

The GBE is not able to access parts from nvram? Have this been tested or is this somewhere explained as a security-functionality?

Side-question: When the Intel ME is not removed, can it access/read any parts of nvram? I ask this because its also defined as a completely separate region in the IFD.

@fhvyhjriur Regions can interact with each other but not at the level you are thinking of. This is low level firmware, not software. Here is the datasheet on the GBE. You can see where GBE components can interact with ME/AMT.

What you are asking for cannot be done. The GBE firmware is loaded and checksum verified at the hardware level, before the BIOS is initialized. This is how PXE and WOL are able to work.

Thanks for the great explanation.

@Thrilleratplay @fhvyhjriur #1195 provides the tools that can extract gbe.bin from maximized builds (flashrom backup) and then apply nvm to the extracted gbe.bin to be injected back into backup.rom.new and flashed back through flashrom by only touching the gbe region.

I changed the name of the issue because it cannot be changed "on boot" for above mentioned reasons.
But it can be modified from Heads and changed on reboot.