Upgrading Intel based platforms with Intel Ethernet (GBE region) sets MAC adress to 00:DE:AD:C0:FF:EE

[nestire]

Please identify some basic details to help process the report

A. Provide Hardware Details

1. What board are you using? (Choose from the list of boards here)

T480 mazimized htop

3. Who installed Heads on this computer?

   • [ X] Self-installed

4. What PGP key is being used?

   • [X ] Nitrokey 3 NFC

5. Are you using the PGP key to provide HOTP verification?

   • [X ] Yes

B. Identify how the board was flashed

1. Is this problem related to updating heads or flashing it for the first time

   • [ X] Updating heads

2. If the problem is related to an update, how did you attempt to apply the update?

   • [X ] Using the Heads menus

3. How was Heads initially flashed?

   • [X] External flashing

4. Was the board flashed with a maximized or non-maximized/legacy rom?

   • [X ] Maximized

5. If Heads was externally flashed, was IFD unlocked?

   • [X] Yes

C. Identify the rom related to this bug report

1. Did you download or build the rom at issue in this bug report?

   • [X ] I downloaded it

2. If you downloaded your rom, where did you get it from?

   • [X] Heads CircleCi

   Please provide the release number or otherwise identify the rom downloaded

3. If you built your rom, which repository:branch did you use?

   • [X ] Heads:Master

Please describe the problem

Describe the bug After an Firmeware upgrade the mac adress of the ethernet interface has the dummy mac adresse 00:de:ad:be:ef thats creates problems in networks

To Reproduce upgrade the Firmware on a t480 check mac adress in the installed OS Expected behavior the mac adress should persist

If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

[nestire]

will create a PR as soon as this is tested

[tlaurion]

This is true for all Intel based laptop boards having gbe configuration blobs to produce a "maximized" rom (which otherwise would be invalid when flashed externally as a whole).

You want to change this for all platforms and document globally that the firmware image contains a forged Mac unless initial flash doesn't overwrite gbe region and that internal upgrading doesn't modify MAC afterward unless gbe added into the flasher command?

[nestire]

For the novacustom version this is allready the case, I think for the firmware upgrade not to touch the gbe is the right call. Where should i document this? to keep this change minimal I'm fine with keeping this to t480 but can allso change this in in all other boards (from my understanding all expect the qemu versions)

[tlaurion]

Where should i document this?

@nestire

All references to flashrom/flashprog in docs (repo https://github.com/linuxboot/heads-wiki rendered over https://osresearch.net), for external initial programmation and for internal programmation if intent is to not disclose any PII identifiable info on network (ie: qubesos refused to randomize wired config for NetworkManager but did for wifi over Accessible Security NLnet grant; so exercice is left to end user, leading to MAC address being forged for all and forcing user to take position if multiple platforms connected on same LAN). This is a community project, which welcomes co-maintainers to emerge with their own agenda, customer needs VS risks acceptance.

If end user is aware he has choice upon initial external flashing then I'm good to change this. If customers are made aware that their wired MAC is a disclosed unique PII on wired networks connected to, I'm ok with this.

Know that this will be effective for roms flashed after the commit fixing this FROM PR. Documentation (Heads and customer facing one) and code PR need to be merged at the same time and users made aware of this philosophy change.

[tlaurion]

@nestire if we go forward and chance of philosophy, all boards having gbe ifd region will need to be skipped, with instructions changed so external flashing doesn't flash over gbe, as for internal flashing per board config changes.

Is this planned from your side? We can't really have one bord doing one thing and then all others doing another thing, otherwise maintainership deathwishez.

[nestire]

@tlaurion yes i can do that just did not want to do the change before we agree on the wording and general sturcture but if this is fine now, I can go over it again and change this in general. From what I see alot of these instruction are not in the wiki but in the code itself or in the heads repo so I would also oben there a PR for that

[tlaurion]

@tlaurion yes i can do that just did not want to do the change before we agree on the wording and general sturcture but if this is fine now, I can go over it again and change this in general. From what I see alot of these instruction are not in the wiki but in the code itself or in the heads repo so I would also oben there a PR for that

This is in board configs, just like for t480/NovaCustom. Basically, all boards for which a coreboot config refers to a gbe should have their board config flash command invoking line changed to specify regions to flash (not including gbe region).

I like what you've done for the heads-wiki. As you saw, a general statement says flashrom/flashprog can be used interchangeably and then pages saying how to init la flash needed to be updated.