[coreboot] Disabling Intel ME 11 via undocumented mode

Timothy Pearson tpearson at raptorengineering.com
Thu Dec 14 17:15:39 CET 2017

Hash: SHA1

Thank you for the detailed response; I figured there had to be some
basic miscommunication somewhere. :-)  So I assume we now agree that the
ME on Sylake + is not disabled, merely limited?

On 12/14/2017 01:20 AM, Youness Alaoui 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.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
Version: GnuPG v1


More information about the coreboot mailing list