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

[Zoran Stojsavljevic]

> 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 running.

I would not say so. I know about the history, and I know a bit about IVB
and BYT GOOGLE orthogonal connections to CCG. Well... INTEL cut these ties,
and now, again, Coreboot is back these days to FSP binary blobs (even more
complex as before, but, seems, there is a better chance to reverse engineer
some parts of it), and similar "venues".

> 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?

On another hand, I should/will agree with you that this, what you have
presented/proposed here, sounds like a plan. Yes, it will be nice to have
all FSP as (open) source code. But I would not run away from/postpone
disabling/neutralising ME after ME is up and running, just to have it
excluded from the up and running system equation.

The complete exclusion, I am afraid, at this point in time, is not possible
(since ME plays core part in bringing up the whole system, especially in
early boot, before even BIOS/FSP starts running). To be more specific, up
to establishing HECI interface.

Anyway, I am learning more, diving deeper in, as we speak. In both
directions: [1] BIOS PEI phase, [2] ME boot up. Long way to go. As I
estimate now the effort. I guess! :-)

Zoran

On Wed, May 3, 2017 at 9:56 PM, Nico Huber <nico.h at gmx.de> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170504/84c660d2/attachment.html>