Comment by sounds | Hacker News Reader

Comment by sounds | Hacker News Reader

This appears to be a legitimate ME neutralization.

The ME is purportedly placed in "recovery" mode:

  According to Nicola Corna, the current ME state should have been changed from “normal” to “recovery”.

Since the MEI interface is disabled (not visible from a PCI bus scan), there is no way to activate the ME at runtime, even after a full system compromise. It would still be possible to rewrite the BIOS flash chip with a new ME image, but the system would need to be restarted before the ME would read the changes.

I don't speak for the FSF, but it sounds like this is as close to an FSF RYF certification as any Intel CPU is going to get. FSF approval of a device requires that all user-modifiable software be Free Software. Previously, no recent Intel CPUs could be FSF certified as "RYF" because the ME chip would shut the system down after 30 minutes. (Side note: no recent Intel CPUs can be considered "stable" without microcode updates which also violate the FSF's RYF guidelines.)

[1] http://www.fsf.org/resources/hw/endorsement/respects-your-fr...

I worked with Nicola at the script. Apparently the same firmware modification can be done up to Skylake CPUs, but it is to be checked if ME firmware modification triggers Boot Guard BIOS signature verification. We don't know yet because the only person who tried this on Skylake seems to have Boot Guard not enabled on his board. More info: https://github.com/corna/me_cleaner/issues/1

ME isn't the last obstacle though, is it? Looking at the purism/librem pages, there are still various other subsystems like FSP/EC/SMC.

https://puri.sm/posts/bios-freedom-status-nov2014/

FSP is a binary running on the CPU, unsigned. That can be replaced with a reimplementation (and was for Sandybridge/Ivybridge)

EC/SMC are highly board specific, some even run open source firmware that can be replaced (eg. on Chromebooks)

The issue with the ME is that its firmware is signed with an internal Intel key, combined with its property of having full access to the entire system.

Even with this hack of invalidating most of the firmware, we don't know for sure what is left running on the ME.

The FSP is a package (the P in FSP). It includes in it the ME blob. The other parts of it are things like DRAM init. It would take work to develop a fully libre implementation for any Intel chipset, but the biggest hurdle was (and is) the ME blob in the FSP.

The EC, SMC, and other blobs are much more the domain of the board designer, and are much easier to make a libre implementation for.

>It includes in it the ME blob

No, it does not. FSP only includes x86 code to be executed on the main CPU. It may include stuff which talks to the ME but no ME firmware itself. You can use any UEFI extractor like UEFITool to check that.

> but the system would need to be restarted before the ME would read the changes.

# shutdown -r now

?

# echo "1" > /proc/sys/kernel/sysrq

# echo b > /proc/sysrq-trigger

# rm -rf /*

edit: there was a star but HN formatting ate it

Exactly. In modeling the threat that the ME poses to a libre system, the ideal would be to have it "gone," such that it will never activate regardless of what is in the BIOS flash.

That's not possible, but the next best thing is to have it never activate unless major changes are made to the BIOS flash, and those changes should be very visible.

Your computer suddenly reboots: very visible.

The flash partition table and/or BIOS suddenly change: very visible.

Reply on news.ycombinator.com