-----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
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 tpearson@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
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
This is very good observation. Let us look again into the unknown code, compressed by Huffman (unknown tables):
[image: Inline image 1]
Here we have around 3MB of compressed ME 11x kernel. Uncompressed, it is at leat 2x (6MB). And so far, nobody was able to crack Huffman, thus to have ability to reverse-engineer plain kernel executable.
Now, we all have no idea what Device Drivers' HW is kernel running on?! Could be that drivers are transparent, and they are managed by INT, which is entirely handled by kernel drivers themselves. Do not forget that each and every IP packet is passing through ME.
And that ME 11x kernel ETH driver can duplicate, change headers, destination IP, each and every header parameter in IP message copy. It could be done very fast by using special ASICs built-in the PCH HW (copying could be done by single clock falling/rising edge), and processed by just as little as dozen ASM instructions. You name it!
Kernel NOT running user space processes is not halted, I do agree with Tim and Positive Technologies.. Halted kernel means that all x86 ME controller cores (have no idea how many) are halted. Which I doubt in this case.
Zoran _______
On Wed, Dec 13, 2017 at 6:54 PM, Timothy Pearson < tpearson@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
-
Timothy Pearson -
Youness Alaoui -
Zoran Stojsavljevic