<div dir="ltr">> 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 <div><br></div><div>This is very good observation. Let us look again into the unknown code, compressed by Huffman (unknown tables):<br><div><br></div><div><img src="cid:ii_160550ca808ac30c" alt="Inline image 1" style="margin-right:0px"><br></div><div><br></div><div>Here we have around 3MB of compressed ME 11x kernel. Uncompressed, it is at leat 2x (6MB). And so far, nobody</div><div>was able to crack Huffman, thus to have ability to reverse-engineer plain kernel executable.</div><div><br></div><div>Now, we all have no idea what Device Drivers' HW is kernel running on?! Could be that drivers are transparent, and</div><div>they are managed by INT, which is entirely handled by kernel drivers themselves. Do not forget that each and every</div><div>IP packet is passing through ME.</div><div><br></div><div>And that ME 11x kernel ETH driver can duplicate, change headers, destination IP, each and every header parameter</div><div>in IP message copy. It could be done very fast by using special ASICs built-in the PCH HW (copying could be done</div><div>by single clock falling/rising edge), and processed by just as little as dozen ASM instructions. You name it!</div><div><br></div><div>Kernel NOT running user space processes is not halted, I do agree with Tim and Positive Technologies.. Halted kernel</div><div>means that all x86 ME controller cores (have no idea how many) are halted. Which I doubt in this case.</div><div><br></div><div>Zoran</div><div class="gmail_extra">_______</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 13, 2017 at 6:54 PM, Timothy Pearson <span dir="ltr"><<a href="mailto:tpearson@raptorengineering.com" target="_blank">tpearson@raptorengineering.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_573085198344740121gmail-">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span>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/201<wbr>7/08/disabling-intel-me.html</a><br>
<div><div class="m_573085198344740121gmail-h5"><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-div<wbr>e-into-intel-me-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>
</div></div><span class="m_573085198344740121gmail-">- --<br>
Timothy Pearson<br>
Raptor Engineering<br>
<a href="tel:%2B1%20%28415%29%20727-8645" value="+14157278645" target="_blank">+1 (415) 727-8645</a> (direct line)<br>
<a href="tel:%2B1%20%28512%29%20690-0200" value="+15126900200" target="_blank">+1 (512) 690-0200</a> (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>
</span>iQEcBAEBAgAGBQJaMWk6AAoJEK+E3v<wbr>EXDOFbTnkH/30CN22Q0JG0bxxvG7Na<wbr>RjUX<br>
i4bsAVpdP+rbd9IlmMHDCPtYnmdoBW<wbr>q81yXZx8iBAzTx5DJrU0lA0Kqr0RzI<wbr>yNRx<br>
pE4omRU2St342bQS5bf/UsFwT2WKR2<wbr>vlE8u8NR4YiOXnJNySJ1gSQqzxB4uG<wbr>wd7I<br>
rcyMnScr4IKEgwiE3GA7HU4vHE2w66<wbr>M6g0skhYQtquAm3ypajmwLUbFwsgiA<wbr>p0l1<br>
Azbt9pUFlp7McZTJusuRroWsDv1oOW<wbr>Qit3nH54i0yP6EajGWbZJ4+sAEQJSX<wbr>Vr9Q<br>
6iuVDE8WfZsydARlvfM+hc0TyrGIv0<wbr>8EnLkhNOQjA4bfab6TxK1l2EnNE1ST<wbr>wXc=<br>
=7rNS<br>
-----END PGP SIGNATURE-----<br>
<div class="m_573085198344740121gmail-HOEnZb"><div class="m_573085198344740121gmail-h5"><br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div></div></div>