Intel Working On Open-Sourcing The FSP - Would Be Huge Win For Coreboot & Security

[starshipeleven]

ME is run on a separate co-processor that has direct memory access and MUST initialize the other processors for the system to boot. It comes with a little ROM built-in the CPU that provides a (exo/pico kernel) OS that reads the UEFI, checks that partitioning, checks the hashes, and if everything signed right, overwrite itself / loads the firmware OS and modules and the CPUs.

No no no. https://github.com/corna/me_cleaner/...oes-it-work%3F

The ME coprocessor is in the chipset, and the ME firmware is in the same flash chip used also by UEFI. (Of course it is in the SoC if we are talking of SoCs like most modern laptop "CPU")

It is loaded by the chipset's boot ROM which also initializes other stuff and loads UEFI from flash.

If it didn't have an ME then UEFI couldn't work since the CPU would blindly start executing the first bits off the EEPROM.

This is complete bullshit, without ME the system is booting fine as the chipset's boot ROM does the initialization up to the UEFI or coreboot+FSP which will then take over and continue as normal, but the system will reset after 30 minutes because of a hardware watchdog that only the ME can shut down.

It's the defining difference between BIOS and UEFI: The first was the entry point for the CPU to initialize from. The latter is where the system ROM which already contains an OS starts loading drivers or an OS.

This sentence makes no sense at all.

Look up why the Talos has two firmwares.

Talos has a BMC, aka "lights out management" which is the Aspeed "GPU" which is not just a GPU but a fully independent crappy ARM SoC with its own RAM and flash, used to remote control servers. This BMC has its own firmware.

For IBM and ARM, the first firmware (that Intel hid in the CPU) is also accessible and writable.

No it's not, the boot ROM can only be stored in a true ROM inside the cpu/chipset/SoC as to do a cold boot you need to have that information on board. Accessing any kind of external memory like SPI chips it too complex to be done by bare hardware.

IBM has opensourced also the microcode of their CPUs I think, which is loaded after the CPU has been actually initialized.

[c117152]

Sorry what?

The ME firmware is stored on flash where the UEFI firmware also is. The only reason it can't be deleted fully is that the ME knows how to disable a hardware watchdog that will reset the board after 30 minutes.

ME is run on a separate co-processor that has direct memory access and MUST initialize the other processors for the system to boot. It comes with a little ROM built-in the CPU that provides a (exo/pico kernel) OS that reads the UEFI, checks that partitioning, checks the hashes, and if everything signed right, overwrite itself / loads the firmware OS and modules and the CPUs.

If it didn't have an ME then UEFI couldn't work since the CPU would blindly start executing the first bits off the EEPROM. It's the defining difference between BIOS and UEFI: The first was the entry point for the CPU to initialize from. The latter is where the system ROM which already contains an OS starts loading drivers or an OS.

Look up why the Talos has two firmwares. For IBM and ARM, the first firmware (that Intel hid in the CPU) is also accessible and writable.

[starshipeleven]

On a similar note, I heard some Ryzen motherboards have the ability to disable PSP with a firmware/BIOS setting. Is there any detailed information or auditing as to what this actually disables?

The description of the feature in my Ryzen mobo says that it will not load a PSP UEFI driver so the "mailbox registers" will not be accessible anymore.

Mailbox registers are used to communicate between two processors on the same SoC, for example the Raspi has mailbox registers to let the CPU communicate with the GPU.

So they are the CPU-PSP communication channel.

[tildearrow]

Was it about FSP or about the ME? I remeber it was about the ME.

It was about the FSP: https://phoronix.com/scan.php?page=n...P-RE-Disappear

[pgeorgi]

On a similar note, I heard some Ryzen motherboards have the ability to disable PSP with a firmware/BIOS setting. Is there any detailed information or auditing as to what this actually disables?

Since on Ryzen, the PSP does even more than the ME does on Intel chipsets (eg. full blown memory init) before taking the x86 CPU out of reset, this is, again, just a "disable the interface" option.

[ssokolow]

Disabling Intel ME for comparison on most newer motherboards only means allowing it to bring up the system, and then either fail (me_cleaner with optional partitions removal), or gracefully stop (HAP bit), or both, and the only feedback I'm aware of to indicate this is from either Intel's own tools (MEInfo), or 3rd-party tools that query for the presence of the IME hardware on PCI (imetool); implying it wouldn't be able to detect anything lower-level (interestingly enough, imetool does fail to find ME at all with either method with me_cleaner, but MEInfo report the full status of ME regardless of the disable method). But what guarantee is there that ME is legitimately not doing anything still?

In more recent Intel hardware, the bring-up and kernel partitions for the ME are signed together, so the "fail" option is no longer available. On those systems, me_cleaner basically strips out as many device drivers from the ME as possible and sets the HAP bit, in the hope that, if there is a backdoor or exploitable hole still accessible with HAP set, exploits against it will depend on access via some of the no-longer-present drivers.

Next year is my bidecennial desktop upgrade. My last two systems were respectively an Intel 920 and 4770k.

The fact ME cleaner exists is the only thing keeping me even remotely interested in Intel products. If I can get coreboot support on whatever next years chips are going to be in a reasonable timeframe they will have saved themselves from an almost certain AMD purchase.

Of course, if AMD were to open source / document / enable alternative firmwares on any of its black box NSA back door hardware that would seal the deal for me as well. But given how they talked about disabling the PSP before backing out and how little interest / participation they have had with Coreboot since Ryzen came out I'm not holding my breath. It is a shame to hear about potentially the first 16 core consumer x86 chip for a reasonable price only to think "such a shame its an untrustable black box". Makes me feel like upgrading from a ME cleaned Haswell chip is a downgrade in freedom.

On a similar note, I heard some Ryzen motherboards have the ability to disable PSP with a firmware/BIOS setting. Is there any detailed information or auditing as to what this actually disables?

Disabling Intel ME for comparison on most newer motherboards only means allowing it to bring up the system, and then either fail (me_cleaner with optional partitions removal), or gracefully stop (HAP bit), or both, and the only feedback I'm aware of to indicate this is from either Intel's own tools (MEInfo), or 3rd-party tools that query for the presence of the IME hardware on PCI (imetool); implying it wouldn't be able to detect anything lower-level (interestingly enough, imetool does fail to find ME at all with either method with me_cleaner, but MEInfo report the full status of ME regardless of the disable method). But what guarantee is there that ME is legitimately not doing anything still?

With the above questions, what would be better for a private computer; a Ryzen motherboard with PSP with only one (optional from motherboard OEM?) known method to turn it off (assuming it actually does), or an Intel board where me_cleaner can gracefully disable ME (HAP bit) without hardware issue?

[starshipeleven]

Does this mean Purism's FSP article can be re-published?

Was it about FSP or about the ME? I remeber it was about the ME.

[starshipeleven]

They probably found a way to sneak the NSA backdoor somewhere else.

It's in the Intel ME

[starshipeleven]

Considering me_cleaner can only turn it off after it initializes the UEFI, I'm guessing the ME is fused read-only on the CPU and only has a little RW space to keep track of FSP versions to prevent rollback attacks and to store patches that it applies live to its memory every time it boots.

Sorry what?

The ME firmware is stored on flash where the UEFI firmware also is. The only reason it can't be deleted fully is that the ME knows how to disable a hardware watchdog that will reset the board after 30 minutes.