[coreboot] Disabling Intel ME 11 via undocumented mode
kakaroto at kakaroto.homelinux.net
Fri Dec 15 02:25:53 CET 2017
In my opinion, the ME is indeed disabled because the entire ME
functionality is disabled, no ME processes are running, and the kernel
on its own is irrelevant, even if it keeps running.
However, I do not have anymore a strong counter opinion to your
statement that you don't consider the ME to be disabled as I
It all depends on how we choose to see it, I consider it to be
disabled, and you consider that it's not. It will always differ on
each person's interpretation of the definition of the word "disabled".
All I could find online about the actual definition of the word
"disabled" is either :
* related to a person, in which the definition is "having a physical
or mental condition that limits movements, senses, or activities."
* related to a device or a mechanism in which the definition is either :
* "rendered inoperative (as by being damaged or deliberately
altered)" (Merriam-Webster dictionary)
* "not in proper working order; out of commission" (Collins dictionary)
The definition of "To disable" is better as it has more meanings
("disabled" has the majority of definitions related to a disabled
* "put out of action" (Oxford dictionary)
* "to make ineffective or inoperative" (Merriam-Webster dictionary)
* "To deprive of capability or effectiveness, especially to impair
the physical abilities of." (The Free Dictionary)
* "to stop a machine or piece of equipment from working properly"
(The MacMillian dictionary)
* "If someone or something disables a system or mechanism, they stop
it working, usually temporarily." (The Collins dictionary)
* "to make ineffective, unfit, or incapable, as by crippling" (The
* "to switch off (an electronic device)" (The Collins dictionary)
I believe that the ME is "disabled" according to all but the last of
these definitions. The ME 11.x with the HAP bit is rendered
ineffective, it's deprived of functionality and it's not working
properly, etc.. The definition which does not match the current status
is the "to switch off", which is not the case here and which is
probably the definition (or close to it) that you have in your mind
when you think of the word "disabled".
So again, like I said, I believe it it disabled and I don't think I'd
be convinced that it's not, but if you say that you don't think it's
disabled, I won't disagree with you either, I'll simply assume you see
things differently. Hopefully, you are also able to understand that
when I say the ME is disabled, it's not because of a desire to
mislead. I believe therefore that we are both right in our
FYI, for me "limited" means that it retains some functionality, but
not all, like for example, the Consumer version of the ME is a limited
ME when compared to the Corporate version. In our case, no
functionality is left, so I can't consider it merely as being limited.
You could say it's limited because the 'kernel functionality' remains,
but I don't see the kernel as a feature, so for me, it doesn't work.
Thanks for reading!
On Thu, Dec 14, 2017 at 11:15 AM, Timothy Pearson
<tpearson at raptorengineering.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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:
>> 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
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> -----END PGP SIGNATURE-----
More information about the coreboot