[coreboot] Disabling Intel ME 11 via undocumented mode

[Zoran Stojsavljevic]

> According to Positive Technologies, on Skylake and higher (like the
> Purism machines) the kernel loads the BUP, and the HAP bit only disables
> the normal userspace processes

This is very good observation. Let us look again into the unknown code,
compressed by Huffman (unknown tables):

[image: Inline image 1]

Here we have around 3MB of compressed ME 11x kernel. Uncompressed, it is at
leat 2x (6MB). And so far, nobody
was able to crack Huffman, thus to have ability to reverse-engineer plain
kernel executable.

Now, we all have no idea what Device Drivers' HW is kernel running on?!
Could be that drivers are transparent, and
they are managed by INT, which is entirely handled by kernel drivers
themselves. Do not forget that each and every
IP packet is passing through ME.

And that ME 11x kernel ETH driver can duplicate, change headers,
destination IP, each and every header parameter
in IP message copy. It could be done very fast by using special ASICs
built-in the PCH HW (copying could be done
by single clock falling/rising edge), and processed by just as little as
dozen ASM instructions. You name it!

Kernel NOT running user space processes is not halted, I do agree with Tim
and Positive Technologies.. Halted kernel
means that all x86 ME controller cores (have no idea how many) are halted.
Which I doubt in this case.

Zoran
_______

On Wed, Dec 13, 2017 at 6:54 PM, Timothy Pearson <
tpearson at raptorengineering.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Positive Technologies, on Skylake and higher (like the
> Purism machines) the kernel loads the BUP, and the HAP bit only disables
> the normal userspace processes [1].
>
> What proof do you have that the kernel itself is halted?
>
> [1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
>
> On 12/13/2017 11:34 AM, Youness Alaoui wrote:
> >> I guess I still disagree with the use of the word "disabled".  If the ME
> >> wasn't required for boot, and was actually disabled within a few cycles
> >> of its CPU starting, the remaining attack surface simply wouldn't exist.
> >>  This is not what happens though, and AFAIK even the ME kernel continues
> >> to run since the ME needs to continue handling platform power events.
> >> If this many holes are present in even the ROM code, then having the ME
> >> kernel running remains a massive security problem.
> >>
> >
> > I'm just going to answer the bit about the use of the term "disabled".
> > I've explained it in my blog post before (here if you missed it :
> > https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do
> > believe the ME is in this case Disabled. What you are thinking about
> > is what I called "Removed". The reason it's called disabled is because
> > the ME stops running, it's not actively doing anything, it doesn't
> > respond to HECI, it doesn't even boot into the kernel. You said that
> > "the ME kernel continues to run", but that's not the case. The entire
> > ME core stops execution during the bring-up phase, so it's technically
> > disabled because it stops itself at some point after boot.
> > Having the ME *removed* would be interesting because that would mean
> > that even the bring up phase wouldn't get executed and we could remove
> > the entire ME firmware from the flash. But that still wouldn't mean
> > that nothing runs on the ME core because there is still some small
> > code embeded in the ROM.
> > Anyways, that's my justification on why using the term "disabled" is
> > valid in this case when HAP is enabled. You are free to disagree if
> > that didn't convince you.
>
>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJaMWk6AAoJEK+E3vEXDOFbTnkH/30CN22Q0JG0bxxvG7NaRjUX
> i4bsAVpdP+rbd9IlmMHDCPtYnmdoBWq81yXZx8iBAzTx5DJrU0lA0Kqr0RzIyNRx
> pE4omRU2St342bQS5bf/UsFwT2WKR2vlE8u8NR4YiOXnJNySJ1gSQqzxB4uGwd7I
> rcyMnScr4IKEgwiE3GA7HU4vHE2w66M6g0skhYQtquAm3ypajmwLUbFwsgiAp0l1
> Azbt9pUFlp7McZTJusuRroWsDv1oOWQit3nH54i0yP6EajGWbZJ4+sAEQJSXVr9Q
> 6iuVDE8WfZsydARlvfM+hc0TyrGIv08EnLkhNOQjA4bfab6TxK1l2EnNE1STwXc=
> =7rNS
> -----END PGP SIGNATURE-----
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171214/8c79ca8a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 90562 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171214/8c79ca8a/attachment-0001.png>