[coreboot] Disabling Intel ME 11 via undocumented mode

[R S]

Thanks for elaborating and shedding light on this for some of us
non-experts who are just lurking around.

On Thu, Dec 14, 2017 at 2:20 AM, Youness Alaoui <
kakaroto at kakaroto.homelinux.net> wrote:

> Hi,
>
> From the PT article you linked to, after the stage 5 of BUP execution :
> "It is at this stage that we find HAP processing; in this mode, BUP
> hangs instead of executing InitScript. This means that the remaining
> sequence of actions in normal mode has nothing to do with HAP and will
> not be considered. The main thing we would like to note is that in HAP
> mode, BUP initializes the entire platform (ICC, Boot Guard) but does
> not start the main ME processes."
>
> As for the kernel, that's my mistake, I remembered that prior to ME
> 11.x, the KERNEL module was removed by me_cleaner, and BUP was the
> first process loaded. I hadn't realized that the execution order
> changed in ME 11.x, and that explains why the KERNEL module cannot be
> removed by me_cleaner in ME 11.x.
> On ME 10.x and lower, the BUP module was the first executed, and it
> would then load the KERNEL, so if BUP is halted before it did that,
> then the kernel doesn't run. In ME 11.x however, they changed the
> order, the KERNEL module is first to be loaded, but it only starts the
> BUP process :
> "The first process that the kernel creates is BUP, which runs in its
> own address space in ring-3. The kernel does not launch any other
> processes itself; this is done by BUP itself"
> So, you are right, on Skylake+ (ME 11.x), the kernel would be running
> but the BUP process is the one halted and no other processes get
> launched, but on ME 10.x and lower, the kernel wouldn't be running
> since BUP is loaded first (this is true for me_cleaned ME 10.x, and
> I'm not sure what exactly the MeAltDisable flag does, which is the
> equivalent of HAP on previous versions, but there wasn't any specific
> research done on that).
>
> I hadn't realized that until now when researching an error-free
> response to you, so thanks for helping me notice that mistake in my
> understanding.
>
> Youness.
>
>
>
> On Wed, Dec 13, 2017 at 12: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
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign <http://comicsanscriminal.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171214/a836095b/attachment.html>