News for hackers. Stuff that matters.

A comment on Neutralize ME Firmware on SandyBridge and IvyBridge Platforms. Parent comment

Re:Neutralize ME Firmware on SandyBridge and IvyBridge Platf... by tunesmith on Monday November 28, 2016 @05:32PM (#13059014)
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/

[ Parent | on HN ]
Re:Neutralize ME Firmware on SandyBridge and IvyBridge Platf... by pgeorgi on Tuesday November 29, 2016 @06:53AM (#13062453)
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.

[ Parent | on HN ]
Re:Neutralize ME Firmware on SandyBridge and IvyBridge Platf... by sounds on Tuesday November 29, 2016 @10:06AM (#13063425)
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.

[ Parent | on HN ]
Re:Neutralize ME Firmware on SandyBridge and IvyBridge Platf... by igor_sk on Monday December 05, 2016 @12:50PM (#13107451)
>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.

[ Parent | on HN ]