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 < kakar...@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 > <tpear...@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@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot@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>
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot