<div dir="ltr">Thanks for elaborating and shedding light on this for some of us non-experts who are just lurking around.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 14, 2017 at 2:20 AM, Youness Alaoui <span dir="ltr"><<a href="mailto:kakaroto@kakaroto.homelinux.net" target="_blank">kakaroto@kakaroto.homelinux.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
>From the PT article you linked to, after the stage 5 of BUP execution :<br>
"It is at this stage that we find HAP processing; in this mode, BUP<br>
hangs instead of executing InitScript. This means that the remaining<br>
sequence of actions in normal mode has nothing to do with HAP and will<br>
not be considered. The main thing we would like to note is that in HAP<br>
mode, BUP initializes the entire platform (ICC, Boot Guard) but does<br>
not start the main ME processes."<br>
<br>
As for the kernel, that's my mistake, I remembered that prior to ME<br>
11.x, the KERNEL module was removed by me_cleaner, and BUP was the<br>
first process loaded. I hadn't realized that the execution order<br>
changed in ME 11.x, and that explains why the KERNEL module cannot be<br>
removed by me_cleaner in ME 11.x.<br>
On ME 10.x and lower, the BUP module was the first executed, and it<br>
would then load the KERNEL, so if BUP is halted before it did that,<br>
then the kernel doesn't run. In ME 11.x however, they changed the<br>
order, the KERNEL module is first to be loaded, but it only starts the<br>
BUP process :<br>
"The first process that the kernel creates is BUP, which runs in its<br>
own address space in ring-3. The kernel does not launch any other<br>
processes itself; this is done by BUP itself"<br>
So, you are right, on Skylake+ (ME 11.x), the kernel would be running<br>
but the BUP process is the one halted and no other processes get<br>
launched, but on ME 10.x and lower, the kernel wouldn't be running<br>
since BUP is loaded first (this is true for me_cleaned ME 10.x, and<br>
I'm not sure what exactly the MeAltDisable flag does, which is the<br>
equivalent of HAP on previous versions, but there wasn't any specific<br>
research done on that).<br>
<br>
I hadn't realized that until now when researching an error-free<br>
response to you, so thanks for helping me notice that mistake in my<br>
understanding.<br>
<span class="HOEnZb"><font color="#888888"><br>
Youness.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Wed, Dec 13, 2017 at 12:54 PM, Timothy Pearson<br>
<<a href="mailto:tpearson@raptorengineering.com">tpearson@raptorengineering.<wbr>com</a>> wrote:<br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA1<br>
><br>
> According to Positive Technologies, on Skylake and higher (like the<br>
> Purism machines) the kernel loads the BUP, and the HAP bit only disables<br>
> the normal userspace processes [1].<br>
><br>
> What proof do you have that the kernel itself is halted?<br>
><br>
> [1] <a href="http://blog.ptsecurity.com/2017/08/disabling-intel-me.html" rel="noreferrer" target="_blank">http://blog.ptsecurity.com/<wbr>2017/08/disabling-intel-me.<wbr>html</a><br>
><br>
> On 12/13/2017 11:34 AM, Youness Alaoui wrote:<br>
>>> I guess I still disagree with the use of the word "disabled".  If the ME<br>
>>> wasn't required for boot, and was actually disabled within a few cycles<br>
>>> of its CPU starting, the remaining attack surface simply wouldn't exist.<br>
>>>  This is not what happens though, and AFAIK even the ME kernel continues<br>
>>> to run since the ME needs to continue handling platform power events.<br>
>>> If this many holes are present in even the ROM code, then having the ME<br>
>>> kernel running remains a massive security problem.<br>
>>><br>
>><br>
>> I'm just going to answer the bit about the use of the term "disabled".<br>
>> I've explained it in my blog post before (here if you missed it :<br>
>> <a href="https://puri.sm/posts/deep-dive-into-intel-me-disablement/" rel="noreferrer" target="_blank">https://puri.sm/posts/deep-<wbr>dive-into-intel-me-<wbr>disablement/</a>) but I do<br>
>> believe the ME is in this case Disabled. What you are thinking about<br>
>> is what I called "Removed". The reason it's called disabled is because<br>
>> the ME stops running, it's not actively doing anything, it doesn't<br>
>> respond to HECI, it doesn't even boot into the kernel. You said that<br>
>> "the ME kernel continues to run", but that's not the case. The entire<br>
>> ME core stops execution during the bring-up phase, so it's technically<br>
>> disabled because it stops itself at some point after boot.<br>
>> Having the ME *removed* would be interesting because that would mean<br>
>> that even the bring up phase wouldn't get executed and we could remove<br>
>> the entire ME firmware from the flash. But that still wouldn't mean<br>
>> that nothing runs on the ME core because there is still some small<br>
>> code embeded in the ROM.<br>
>> Anyways, that's my justification on why using the term "disabled" is<br>
>> valid in this case when HAP is enabled. You are free to disagree if<br>
>> that didn't convince you.<br>
><br>
><br>
> - --<br>
> Timothy Pearson<br>
> Raptor Engineering<br>
> +1 (415) 727-8645 (direct line)<br>
> +1 (512) 690-0200 (switchboard)<br>
> <a href="https://www.raptorengineering.com" rel="noreferrer" target="_blank">https://www.raptorengineering.<wbr>com</a><br>
> -----BEGIN PGP SIGNATURE-----<br>
> Version: GnuPG v1<br>
><br>
> iQEcBAEBAgAGBQJaMWk6AAoJEK+<wbr>E3vEXDOFbTnkH/<wbr>30CN22Q0JG0bxxvG7NaRjUX<br>
> i4bsAVpdP+<wbr>rbd9IlmMHDCPtYnmdoBWq81yXZx8iB<wbr>AzTx5DJrU0lA0Kqr0RzIyNRx<br>
> pE4omRU2St342bQS5bf/<wbr>UsFwT2WKR2vlE8u8NR4YiOXnJNySJ1<wbr>gSQqzxB4uGwd7I<br>
> rcyMnScr4IKEgwiE3GA7HU4vHE2w66<wbr>M6g0skhYQtquAm3ypajmwLUbFwsgiA<wbr>p0l1<br>
> Azbt9pUFlp7McZTJusuRroWsDv1oOW<wbr>Qit3nH54i0yP6EajGWbZJ4+<wbr>sAEQJSXVr9Q<br>
> 6iuVDE8WfZsydARlvfM+<wbr>hc0TyrGIv08EnLkhNOQjA4bfab6TxK<wbr>1l2EnNE1STwXc=<br>
> =7rNS<br>
> -----END PGP SIGNATURE-----<br>
><br>
> --<br>
> coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
> <a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Tech III * AppControl * Endpoint Protection * Server Maintenance<br>Buncombe County Schools Technology Department Network Group<br><a href="http://comicsanscriminal.com" target="_blank">ComicSans Awareness Campaign</a></div></div></div></div></div></div>
</div>