3 ms·
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 h
by sounds 10y ago
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-freedom http://www.fsf.org/resources/hw/endorsement/respects-your-fr...
- tunesmith 10y agoME 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/ https://puri.sm/posts/bios-freedom-status-nov2014/
- pgeorgi 10y agoFSP 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.
- sounds 10y agoThe 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.
- igor_sk 10y ago>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.
- fizzo 10y agoI 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 https://github.com/corna/me_cleaner/issues/1
- discardorama 10y ago> but the system would need to be restarted before the ME would read the changes. # shutdown -r now ?
- therein 10y ago# echo "1" > /proc/sys/kernel/sysrq # echo b > /proc/sysrq-trigger
- tscs37 10y ago# rm -rf /* edit: there was a star but HN formatting ate it
- sounds 10y agoExactly. 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.