[coreboot] Remote security exploit in all 2008+ Intel platforms

[Nico Huber]

On 03.05.2017 09:28, Zoran Stojsavljevic wrote:
>> The reason we want to prioritize the ME vs. the FSP, is because a lot
> more people were interested in getting rid of the ME,
>> so it is a higher priority, *but the FSP is also going to be reversed
> eventually and coreboot deblobbed entirely*.
> 
> This is very serious claim, Youness. In FSP you do have much more than ONLY
> MRC (actually, several MRC algorithms, a bunch tied/bundled together,
> depending upon what the initial DRAM SPD discovery mechanism is, my best
> guess). You do have BSP CPU init, then APP CPU(s) init(s), and then PCH
> init as well, on the system registry level. There is also platform init
> phase in there, the very minimal one. Also I throw-in PCIe discovery
> algorithm. Serious stuff.

Serious stuff, sure. But it has been done before (without anyone being
payed for it, FWIW). And compared to the ME firmware we know what it
has to do _and_ don't have to hack into anything to get our code run-
ning.

> 
> If you ask me, I would keep up with disabling ME on application level
> (since ME FW booting is A MUST, as my best understanding of ME FW stands
> for now). In other words, if I guessed correctly, to make newest ME 11.x
> engine, based on x86 HW (quark most likely), to run idler process all the
> time, if Dmitry is correct, and we have MINIX3 micro-kernel running on the
> top of quark there.
> 
> Divide and Conquer, the evergreen idiom: first to take ME, FSP should come
> after (they can be well divided)... ;-)

Why ME first? What is a free ME good for if you don't control the main
(um, how to call it if both are x86?) processor?

Nico