Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Felix Held]

And so far, nobody was able to crack Huffman, thus to have ability to 
reverse-engineer plain kernel executable.


Not true. See 
http://blog.ptsecurity.com/2017/12/huffman-tables-intel-me.html , 
https://github.com/ptresearch/unME11 and 
https://github.com/IllegalArgument/Huffman11


Regards
Felix

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Gregg Levine]

Hello!
(Today on my regular laptop who might be so gifted with the Intel ME.)
All this nattering and grommishing around about the Intel ME device is
interesting and fun sort-of. But this does not explain what the Intel
ME is and what it does. And what about it has caused an almost
incredible display of discussions on both this list, and the Hack A
Day regular blog.

For example this laptop does run Linux and in fact does host my
(occasional) efforts to explore the meaning behind coreboot and its
ancestors.

What would be the indicators  to look for via the lspci command? And
what is interesting is that I ran the Windows(!) version of the Intel
tool to tell me what to look for.Suffice to say the response was
confusing,.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Sat, Dec 16, 2017 at 4:03 PM, Denis 'GNUtoo' Carikli
 wrote:
> On Thu, 14 Dec 2017 20:25:53 -0500
> Youness Alaoui  wrote:
>
>> 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
>> originally did.
>> 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 :
> [...]
>>   * "rendered inoperative (as by being damaged or deliberately
>> altered)" (Merriam-Webster dictionary)
> [...]
>>   * "to make ineffective or inoperative" (Merriam-Webster dictionary)
>>   * "To deprive of capability or effectiveness, especially to impair
> I find it more interesting to try to explain what is really going on to
> people, by using some construct like that:
> "disabled/limited/etc" by , with the first part
> being a judgment of the person writing that over what is acceptable or
> not, and the last part that tries to explain what it really means, so
> the people reading it could still have their own judgment on whether
> they consider it acceptable or not.
>
> Denis.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Denis 'GNUtoo' Carikli]

On Thu, 14 Dec 2017 20:25:53 -0500
Youness Alaoui  wrote:

> 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
> originally did.
> 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 :
[...]
>   * "rendered inoperative (as by being damaged or deliberately
> altered)" (Merriam-Webster dictionary)
[...]
>   * "to make ineffective or inoperative" (Merriam-Webster dictionary)
>   * "To deprive of capability or effectiveness, especially to impair
I find it more interesting to try to explain what is really going on to
people, by using some construct like that:
"disabled/limited/etc" by , with the first part
being a judgment of the person writing that over what is acceptable or
not, and the last part that tries to explain what it really means, so
the people reading it could still have their own judgment on whether
they consider it acceptable or not.

Denis.


pgpUKR6tBdt6W.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Zoran Stojsavljevic]

> pretty sure the I is for Intel ;-)

Sure. AMD has AME, as I recall. VIA has VME, Cyrix had CME, etc. ;-)

It is ME, simple and plain. I(ntel)ME is a pleonasm (please, look on the
Webster Dictionary what the pleonasm is?!).

Zoran

On Fri, Dec 15, 2017 at 6:18 PM, Matt DeVillier 
wrote:

> On Fri, Dec 15, 2017 at 10:23 AM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>>  IME (I is typo) = ME .
>>
>
> pretty sure the I is for Intel ;-)
>
> (or, at least that's how I've seen it referenced elsewhere)
>
>
>>
>> Zoran
>>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Matt DeVillier]

On Fri, Dec 15, 2017 at 10:23 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

>  IME (I is typo) = ME .
>

pretty sure the I is for Intel ;-)

(or, at least that's how I've seen it referenced elsewhere)


>
> Zoran
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Zoran Stojsavljevic]

 IME (I is typo) = ME .

Zoran

On Fri, Dec 15, 2017 at 5:14 PM, Gregg Levine 
wrote:

> Hello!
> (I'm working from the office today on a library computer...)
> My regular laptop might be wearing one of those dratted things. But
> before we start confusing people further, perhaps one of the group
> needs to reiterate exactly what that contraption is, and why it was
> necessary. Oh and what the cleaner is supposed to do, and why machines
> who were cleaned of it, may not work correctly, or even may.
>
> I've got an interesting idea that I do know what it does, and why, but
> there must be a few people there who're confused about what the IME is
> and isn't.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>
>
> On Fri, Dec 15, 2017 at 10:00 AM, Philipp Stanner 
> wrote:
> > Thanks.
> >
> > They didn't seriously include a Java Runtime Environment into the IME??
> > I can't believe what's going on with this company.
> >
> > Am Freitag, den 08.12.2017, 16:16 +0100 schrieb Thomas Heijligen:
> >> For those who are interested in the Intel ME, the slides and white
> >> papers
> >> from the Black Hat Europe are public.
> >>
> >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
> >> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
> >> Management-Engine.pdf
> >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
> >> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
> >> Management-Engine-wp.pdf
> >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
> >> -Flash-File-System-Explained.pdf
> >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
> >> -Flash-File-System-Explained-wp.pdf
> >>
> >> In the conclusion they say "[...]. Such a vulnerability has  the
> >> potential  to
> >> jeopardize a number  of  technologies,  including [...] Intel Boot
> >> Guard
> >> [...].
> >>
> >> Maybe it's possible to deactivate Boot Guard permanently or inject
> >> custom
> >> keys to run own firmware.
> >>
> >>
> >> On 08.12.2017 15:40, Alberto Bursi wrote:
> >> > On 12/08/2017 02:59 PM, Timothy Pearson wrote:
> >> > >
> >> > > That's just the HAP bit.  The ME is limited but NOT disabled, and
> >> > > the
> >> > > remaining stubs are still hackable [1].
> >> > >
> >> > > Neither the ME or the PSP can ever be removed from their
> >> > > respective
> >> > > systems.  They can both be limited to some extent, but to call
> >> > > either
> >> > > of
> >> > > them "disabled" is rather far from the truth.
> >> > >
> >> > >
> >> >
> >> > Hacking them requires being able to write in the SPI flash, or to
> >> > have
> >> > buggy UEFI firmware. Which means most systems are still vulnerable.
> >> >
> >> > But it is also true that if someone can hack UEFI he pwns you
> >> > anyway,
> >> > even without ME.
> >> >
> >> > So imho ME with the HAP bit can be called "disabled", although the
> >> > fight
> >> > isn't over as ME isn't the only thing that was a threat anyway.
> >> >
> >> > There is still need to secure the UEFI firmware (which is needed
> >> > even
> >> > if
> >> > ME didn't exist), and doing a hardware mod to have a hardware
> >> > switch to
> >> > turn the SPI chip read-only at the hardware level (also needed
> >> > regardless of ME).
> >> >
> >> > I think many SPI chips only need some pin pulled high/low to go in
> >> > read-only mode, and I frankly trust a dumb switch many orders of
> >> > magnitude more than Boot Guard or anything software-based.
> >> >
> >> > -Alberto
> >>
> >>
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Gregg Levine]

Hello!
(I'm working from the office today on a library computer...)
My regular laptop might be wearing one of those dratted things. But
before we start confusing people further, perhaps one of the group
needs to reiterate exactly what that contraption is, and why it was
necessary. Oh and what the cleaner is supposed to do, and why machines
who were cleaned of it, may not work correctly, or even may.

I've got an interesting idea that I do know what it does, and why, but
there must be a few people there who're confused about what the IME is
and isn't.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Fri, Dec 15, 2017 at 10:00 AM, Philipp Stanner  wrote:
> Thanks.
>
> They didn't seriously include a Java Runtime Environment into the IME??
> I can't believe what's going on with this company.
>
> Am Freitag, den 08.12.2017, 16:16 +0100 schrieb Thomas Heijligen:
>> For those who are interested in the Intel ME, the slides and white
>> papers
>> from the Black Hat Europe are public.
>>
>> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
>> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
>> Management-Engine.pdf
>> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
>> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
>> Management-Engine-wp.pdf
>> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
>> -Flash-File-System-Explained.pdf
>> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
>> -Flash-File-System-Explained-wp.pdf
>>
>> In the conclusion they say "[...]. Such a vulnerability has  the
>> potential  to
>> jeopardize a number  of  technologies,  including [...] Intel Boot
>> Guard
>> [...].
>>
>> Maybe it's possible to deactivate Boot Guard permanently or inject
>> custom
>> keys to run own firmware.
>>
>>
>> On 08.12.2017 15:40, Alberto Bursi wrote:
>> > On 12/08/2017 02:59 PM, Timothy Pearson wrote:
>> > >
>> > > That's just the HAP bit.  The ME is limited but NOT disabled, and
>> > > the
>> > > remaining stubs are still hackable [1].
>> > >
>> > > Neither the ME or the PSP can ever be removed from their
>> > > respective
>> > > systems.  They can both be limited to some extent, but to call
>> > > either
>> > > of
>> > > them "disabled" is rather far from the truth.
>> > >
>> > >
>> >
>> > Hacking them requires being able to write in the SPI flash, or to
>> > have
>> > buggy UEFI firmware. Which means most systems are still vulnerable.
>> >
>> > But it is also true that if someone can hack UEFI he pwns you
>> > anyway,
>> > even without ME.
>> >
>> > So imho ME with the HAP bit can be called "disabled", although the
>> > fight
>> > isn't over as ME isn't the only thing that was a threat anyway.
>> >
>> > There is still need to secure the UEFI firmware (which is needed
>> > even
>> > if
>> > ME didn't exist), and doing a hardware mod to have a hardware
>> > switch to
>> > turn the SPI chip read-only at the hardware level (also needed
>> > regardless of ME).
>> >
>> > I think many SPI chips only need some pin pulled high/low to go in
>> > read-only mode, and I frankly trust a dumb switch many orders of
>> > magnitude more than Boot Guard or anything software-based.
>> >
>> > -Alberto
>>
>>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Philipp Stanner]

Thanks.

They didn't seriously include a Java Runtime Environment into the IME??
I can't believe what's going on with this company.

Am Freitag, den 08.12.2017, 16:16 +0100 schrieb Thomas Heijligen:
> For those who are interested in the Intel ME, the slides and white 
> papers
> from the Black Hat Europe are public.
> 
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
> Management-Engine.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H
> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
> Management-Engine-wp.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
> -Flash-File-System-Explained.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME
> -Flash-File-System-Explained-wp.pdf
> 
> In the conclusion they say "[...]. Such a vulnerability has  the  
> potential  to
> jeopardize a number  of  technologies,  including [...] Intel Boot
> Guard 
> [...].
> 
> Maybe it's possible to deactivate Boot Guard permanently or inject 
> custom
> keys to run own firmware.
> 
> 
> On 08.12.2017 15:40, Alberto Bursi wrote:
> > On 12/08/2017 02:59 PM, Timothy Pearson wrote:
> > > 
> > > That's just the HAP bit.  The ME is limited but NOT disabled, and
> > > the
> > > remaining stubs are still hackable [1].
> > > 
> > > Neither the ME or the PSP can ever be removed from their
> > > respective
> > > systems.  They can both be limited to some extent, but to call
> > > either 
> > > of
> > > them "disabled" is rather far from the truth.
> > > 
> > > 
> > 
> > Hacking them requires being able to write in the SPI flash, or to
> > have
> > buggy UEFI firmware. Which means most systems are still vulnerable.
> > 
> > But it is also true that if someone can hack UEFI he pwns you
> > anyway,
> > even without ME.
> > 
> > So imho ME with the HAP bit can be called "disabled", although the 
> > fight
> > isn't over as ME isn't the only thing that was a threat anyway.
> > 
> > There is still need to secure the UEFI firmware (which is needed
> > even 
> > if
> > ME didn't exist), and doing a hardware mod to have a hardware
> > switch to
> > turn the SPI chip read-only at the hardware level (also needed
> > regardless of ME).
> > 
> > I think many SPI chips only need some pin pulled high/low to go in
> > read-only mode, and I frankly trust a dumb switch many orders of
> > magnitude more than Boot Guard or anything software-based.
> > 
> > -Alberto
> 
> 

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

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
originally did.
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
person) :
  * "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
Collins dictionary)
  * "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
interpretations.
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!
Youness.


On Thu, Dec 14, 2017 at 11:15 AM, Timothy Pearson
 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:
>> 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 

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-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:
> 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)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaMqOoAAoJEK+E3vEXDOFb/mEH/3Wm0Zgt1xuZA1pvpeOC8+WG
kTwczb/18V6fGLHK0SoGX7ynA4+siU+dRHwVX+uharkxED5/d4VCWnb7tUWsiT2s
7EYfYoySXgC1IDJwTZ6UxtDfh+zc5EFlm7ZLdOBXkLq07CSffqRrrbaQuJTj6QwQ
wijT5Y9xhx0xVkDTDRO+unG4evAHUamrUOvIF+qranZiKbhFwI5nE+1LU8jcluQ4
2AxkxUqj0hhvEBn2Zkg+LnJbcwnTr3tpmpp5A/bWOZoYZo/Z4vE52RXs9f5ReiWM
ZwQH6YH6cHZpnThgTM2wUEJszjSJLr2tvXGXqFXvwFAlQjegGo3pCM7NE7bk9Hg=
=8p+9
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Zoran Stojsavljevic]

> 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 <
tpear...@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
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[R S]

Thanks for elaborating and shedding light on this for some of us
non-experts who are just lurking around.

On Thu, Dec 14, 2017 at 2:20 AM, Youness Alaoui <
kakar...@kakaroto.homelinux.net> 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.
>
>
>
> On Wed, Dec 13, 2017 at 12:54 PM, Timothy Pearson
>  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
> > 

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

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
 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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-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

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

> 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.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[taii...@gmx.com]

On 12/12/2017 12:11 PM, Denis 'GNUtoo' Carikli wrote:


As I understand, this by itself isn't sufficient yet to boot a post-GM45
Intel with free software, however it gives a lot of insight on how
things work and enables all researchers to understand better the
Management Engine and recent Intel systems to, maybe one day, make free
software booting possible on such platforms.

I hope that one day someone would find and publish a way to do that,
like for instance by finding a bit in the flash descriptor that would
enable "PCH red unlock".

As I understand enabling DCI is already possible trough some flash
descriptor bits.

Thanks a lot for all the research that was done!

Denis.
As I have stated before it simply doesn't matter if some day an ME hack 
is discovered to be able to have a "libre" intel desktop, because the 
vendor (intel) is hostile to owner control it will be quickly fixed and 
thus one should support owner controller hardware such as POWER (where 
one can even change the microcode) instead of giving them more money to 
make better anti-features.


At least one shuld buy used hardware and not new hardware if they insist 
on x86-64.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Denis 'GNUtoo' Carikli]

On Fri, 8 Dec 2017 21:34:57 +0100 (CET)
eche...@free.fr wrote:

> For those who are interested in the Intel ME, the slides and white 
> papers
> from the Black Hat Europe are public.
> 
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine-wp.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-File-System-Explained.pdf
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-File-System-Explained-wp.pdf
I read the documents above and in:
> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine-wp.pdf
we have:
> The file /home/bup/ct
> was unsigned, enabling us to slip a modified version into the ME
> firmware with the help of Flash Image Tool.
> Now we were able to cause a buffer overflow inside the
> BUP process with the help of a large BUP initialization file.
[...]
> By exploiting the vulnerability that we found in the bup module, we
> were able to turn on a mechanism, PCH red unlock, that opens full
> access to all PCH devices for their use via the DFx chain—in other
> words, using JTAG. One such device is the x86 ME processor itself,
> and so we obtained access to its internal JTAG interface. With such
> access, we could debug code executed on ME, read memory of all
> processes and the kernel, and manage all devices inside the PCH. We
> found a total of about 50 internal devices to which only ME has full
> access, while the main processor has access only to a very limited
> subset of them.
As I understand, this by itself isn't sufficient yet to boot a post-GM45
Intel with free software, however it gives a lot of insight on how
things work and enables all researchers to understand better the
Management Engine and recent Intel systems to, maybe one day, make free
software booting possible on such platforms.

I hope that one day someone would find and publish a way to do that,
like for instance by finding a bit in the flash descriptor that would
enable "PCH red unlock".

As I understand enabling DCI is already possible trough some flash
descriptor bits.

Thanks a lot for all the research that was done!

Denis.


pgpHuiD9lzfx2.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Thomas Heijligen]

For those who are interested in the Intel ME, the slides and white 
papers

from the Black Hat Europe are public.

https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine-wp.pdf
https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-File-System-Explained.pdf
https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-File-System-Explained-wp.pdf

In the conclusion they say "[...]. Such a vulnerability has  the  
potential  to
jeopardize a number  of  technologies,  including [...] Intel Boot Guard 
[...].


Maybe it's possible to deactivate Boot Guard permanently or inject 
custom

keys to run own firmware.


On 08.12.2017 15:40, Alberto Bursi wrote:

On 12/08/2017 02:59 PM, Timothy Pearson wrote:


That's just the HAP bit.  The ME is limited but NOT disabled, and the
remaining stubs are still hackable [1].

Neither the ME or the PSP can ever be removed from their respective
systems.  They can both be limited to some extent, but to call either 
of

them "disabled" is rather far from the truth.




Hacking them requires being able to write in the SPI flash, or to have
buggy UEFI firmware. Which means most systems are still vulnerable.

But it is also true that if someone can hack UEFI he pwns you anyway,
even without ME.

So imho ME with the HAP bit can be called "disabled", although the 
fight

isn't over as ME isn't the only thing that was a threat anyway.

There is still need to secure the UEFI firmware (which is needed even 
if

ME didn't exist), and doing a hardware mod to have a hardware switch to
turn the SPI chip read-only at the hardware level (also needed
regardless of ME).

I think many SPI chips only need some pin pulled high/low to go in
read-only mode, and I frankly trust a dumb switch many orders of
magnitude more than Boot Guard or anything software-based.

-Alberto


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Zoran Stojsavljevic]

> Neither the ME or the PSP can ever be removed from their respective
systems.

I already wrote extensively about this in the previous thread (I 1000%
agree with you, Tim). But these people revealed
the almost whole architecture how ME boots the modern INTEL platform, and,
frankly, I never expected that this will be
described very precisely, as they did.

In other words, I never would have expected the description how BUP and
stages work, and other details (what they
wrote/investigated in that article) will ever see/emerge on the Day Light!
:-)

Zoran

On Fri, Dec 8, 2017 at 2:59 PM, Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> That's just the HAP bit.  The ME is limited but NOT disabled, and the
> remaining stubs are still hackable [1].
>
> Neither the ME or the PSP can ever be removed from their respective
> systems.  They can both be limited to some extent, but to call either of
> them "disabled" is rather far from the truth.
>
> This all being said, it's great to see a light being shed on the ME.  It
> shows just how dangerous an embedded, mandatory core with signed
> firmware can be.
>
> [1] https://twitter.com/rootkovska/status/938458875522666497
>
> On 12/08/2017 07:51 AM, Zoran Stojsavljevic wrote:
> > Disabling Intel ME 11 via undocumented mode
> > http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
> >
> > I just managed (few hours ago) to read this article (way after replying
> > to previous thread about Dell HAP, I read only few intro paragraphs)...
> > It is, after all, amazing how far these two people, *Mark Ermolov and
> > Maxim Goryachy* progressed with ME debugging/cracking
> > and understanding how ME is connected/related to the INTEL platforms'
> > bring up!
> >
> > I just stumbled over it upon searching about ME, and I know what they
> > did achieve previously. They achieved some
> > steps forward... :-)
> >
> > I did not see that this article was published before on Coreboot (excuse
> > me for my ignorance if I missed it), but it is worth
> > reading, every word of it, especially the second part!
> >
> > What is described on the second part is way (much) more than I was
> > willing to lament on (since in the lieu of the Legal
> > issues). Especially on BringUP stages. Excellent read!
> >
> > Something is definitely changing in the Open Source World... And I say,
> > I am very happy to read such articles!
> >
> > Man, there are very serious people out there trying to demystify secrets.
> >
> > I will read again this article later, very concentrated... Trying to put
> > some more comprehensive picture in my mind.
> >
> > Thank you, all of you, Black Hat, Positive Technology, and others!
> >
> > Molodci, rebjata!
> >
> > Zoran
> >
>
>
> - --
> 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
>
> iQEcBAEBAgAGBQJaKprdAAoJEK+E3vEXDOFbvZUH/0NN/gXYoyR3UIi/JWtZliYL
> bo7UAdl7lzLHPzNcZLBeuoYFICl38qKStS/fOHtDj8kHqRzSrMsrWsp7o11K8JjL
> vypOIhXnb+S+zBPI9e/ZLx6d9EKSV6KgWQJnVnzdh5ynNP+duR7Hbc322fu0qb/O
> XbEyZwlwmMwT9+OJ6fRusyACMdf8RtOrgrg3lyJ4oW66s48RYr3UN+PLImwYH3fX
> 2Kid5DxtqMQ2BR6cDHKnlGJuV+X83CTZempfgodJWSaQneg7tKqwCa39/Zv9FbC6
> RFQ4Z3gkGtXDl4Br2ovxHcuqUtMuuVUwYSoa31nilu0GJRVpA2mgjVMxVw7UGf0=
> =AeQJ
> -END PGP SIGNATURE-
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/08/2017 08:40 AM, Alberto Bursi wrote:
> 
> 
> On 12/08/2017 02:59 PM, Timothy Pearson wrote:
>>
>> That's just the HAP bit.  The ME is limited but NOT disabled, and the
>> remaining stubs are still hackable [1].
>>
>> Neither the ME or the PSP can ever be removed from their respective
>> systems.  They can both be limited to some extent, but to call either of
>> them "disabled" is rather far from the truth.
>>
>>
> 
> Hacking them requires being able to write in the SPI flash, or to have 
> buggy UEFI firmware. Which means most systems are still vulnerable.
> 
> But it is also true that if someone can hack UEFI he pwns you anyway, 
> even without ME.
> 
> So imho ME with the HAP bit can be called "disabled", although the fight 
> isn't over as ME isn't the only thing that was a threat anyway.

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.

Pretty much every computing platform, with the exception of some of the
ARM SBCs with key fuses or Talos with FlexVer, are vulnerable to attack
via Flash reprogramming, so I agree that this in and of itself should
not be a disqualifier for many use cases.  I simply take issue with
calling the ME "disabled" when the reality is very different.

- -- 
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

iQEcBAEBAgAGBQJaKqe8AAoJEK+E3vEXDOFblnQH/0tvczmOm+8UfyBLdaZiLta1
d4iUhn1lotThx/tAxdBfpn3FqRPtfbFfNfEIyqjIqiTHVVKMTHVb+Z/5BY66eNvy
d5D3BbK4wu4A6SHho5/oxNw6RGSy9YqAhJwtSdmBNMyVnU6KVcRzyrPzb+fgWQac
vEYIik4Z+cZAmQqk37dBgPQGJT706DL55NJyiKjii9+MSYxPTlF0yogUYB93SNAw
x5V0rZoGkx9GTHCKL+MSIB9INBROQ/fc2C8TLQS/lSA4vZD7pHHVynsL3wTcqppB
rM3GMIC7xu88qpsR0ZwJ4YqaejwDmqgVYPCA0pv9be0mR2OZ878k53fLKKaOigc=
=yNRx
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Alberto Bursi]

On 12/08/2017 02:59 PM, Timothy Pearson wrote:
>
> That's just the HAP bit.  The ME is limited but NOT disabled, and the
> remaining stubs are still hackable [1].
>
> Neither the ME or the PSP can ever be removed from their respective
> systems.  They can both be limited to some extent, but to call either of
> them "disabled" is rather far from the truth.
>
>

Hacking them requires being able to write in the SPI flash, or to have 
buggy UEFI firmware. Which means most systems are still vulnerable.

But it is also true that if someone can hack UEFI he pwns you anyway, 
even without ME.

So imho ME with the HAP bit can be called "disabled", although the fight 
isn't over as ME isn't the only thing that was a threat anyway.

There is still need to secure the UEFI firmware (which is needed even if 
ME didn't exist), and doing a hardware mod to have a hardware switch to 
turn the SPI chip read-only at the hardware level (also needed 
regardless of ME).

I think many SPI chips only need some pin pulled high/low to go in 
read-only mode, and I frankly trust a dumb switch many orders of 
magnitude more than Boot Guard or anything software-based.

-Alberto
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That's just the HAP bit.  The ME is limited but NOT disabled, and the
remaining stubs are still hackable [1].

Neither the ME or the PSP can ever be removed from their respective
systems.  They can both be limited to some extent, but to call either of
them "disabled" is rather far from the truth.

This all being said, it's great to see a light being shed on the ME.  It
shows just how dangerous an embedded, mandatory core with signed
firmware can be.

[1] https://twitter.com/rootkovska/status/938458875522666497

On 12/08/2017 07:51 AM, Zoran Stojsavljevic wrote:
> Disabling Intel ME 11 via undocumented mode
> http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
> 
> I just managed (few hours ago) to read this article (way after replying
> to previous thread about Dell HAP, I read only few intro paragraphs)...
> It is, after all, amazing how far these two people, *Mark Ermolov and
> Maxim Goryachy* progressed with ME debugging/cracking
> and understanding how ME is connected/related to the INTEL platforms'
> bring up!
> 
> I just stumbled over it upon searching about ME, and I know what they
> did achieve previously. They achieved some
> steps forward... :-)
> 
> I did not see that this article was published before on Coreboot (excuse
> me for my ignorance if I missed it), but it is worth
> reading, every word of it, especially the second part!
> 
> What is described on the second part is way (much) more than I was
> willing to lament on (since in the lieu of the Legal
> issues). Especially on BringUP stages. Excellent read!
> 
> Something is definitely changing in the Open Source World... And I say,
> I am very happy to read such articles!
> 
> Man, there are very serious people out there trying to demystify secrets.
> 
> I will read again this article later, very concentrated... Trying to put
> some more comprehensive picture in my mind.
> 
> Thank you, all of you, Black Hat, Positive Technology, and others!
> 
> Molodci, rebjata!
> 
> Zoran
> 


- -- 
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

iQEcBAEBAgAGBQJaKprdAAoJEK+E3vEXDOFbvZUH/0NN/gXYoyR3UIi/JWtZliYL
bo7UAdl7lzLHPzNcZLBeuoYFICl38qKStS/fOHtDj8kHqRzSrMsrWsp7o11K8JjL
vypOIhXnb+S+zBPI9e/ZLx6d9EKSV6KgWQJnVnzdh5ynNP+duR7Hbc322fu0qb/O
XbEyZwlwmMwT9+OJ6fRusyACMdf8RtOrgrg3lyJ4oW66s48RYr3UN+PLImwYH3fX
2Kid5DxtqMQ2BR6cDHKnlGJuV+X83CTZempfgodJWSaQneg7tKqwCa39/Zv9FbC6
RFQ4Z3gkGtXDl4Br2ovxHcuqUtMuuVUwYSoa31nilu0GJRVpA2mgjVMxVw7UGf0=
=AeQJ
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Merlin Büge]

On Wed, 30 Aug 2017 18:09:51 -0400
"taii...@gmx.com"  wrote:

> On 08/30/2017 03:28 PM, Timothy Pearson wrote:
> 
> >> POWER9 workstations are already coming on the market:
> >>
> >> https://raptorcs.com/TALOSII/
> >>
> >> Note that IBM selling similar machines directly would likely be
> >> more expensive, not less, based on POWER8 price comparisons
> >> between IBM and other vendors.  People purchase IBM branded
> >> products for extreme reliability, not to get cheap equipment...
> Damn that is sick as hell! you guys actually pulled it off! how did
> you get the funding? how have I not heard about this before?

Yeah, I wonder why it was not announced on this list. Although not
directly coreboot related, there probably is strong interest here
within this community.

There is also a channel on freenode: #talos-workstation

>From what I've heard, pre-orders will close very soon, and it's unknown
if there will be a second production run of the boards...

Timothy, maybe you could shed some light on it?


Cheers,

Merlin

 

> 
> -- 
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot


-- 
Merlin Büge 

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[taii...@gmx.com]

On 08/30/2017 03:28 PM, Timothy Pearson wrote:


POWER9 workstations are already coming on the market:

https://raptorcs.com/TALOSII/

Note that IBM selling similar machines directly would likely be more
expensive, not less, based on POWER8 price comparisons between IBM and
other vendors.  People purchase IBM branded products for extreme
reliability, not to get cheap equipment...
Damn that is sick as hell! you guys actually pulled it off! how did you 
get the funding? how have I not heard about this before?


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Felipe Sanches]

Try this backup copy from the Internet Archive:

https://web.archive.org/web/20121211162830/fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf

2017-08-30 1:00 GMT-03:00 taii...@gmx.com :

> I can't download the .pdf file for some reason (maybe the tla's got to it?)
> http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf
> can someone send it to me?
> Thanks
>
>
> Thoughts:
> Sad this is still not an actual method of disablement, but it doesn't
> really matter as anyone who buys *new* x86 hardware is still supporting
> wintel's development of newer and better anti-features, DRM and
> surveillance technology - one that can't even be me-cleaner/hap/etc nerfed
> will be released some day. I wish people spent their energy popularizing
> owner controlled arches instead of beating a dead horse.
>
> While IBM also makes surveillance tech they make POWER which as the last
> performance owner controlled arch that sells for attainable prices goes a
> long way to offset that. Heres to hoping IBM starts selling POWER
> workstations...
>
> I find it hard to believe that the NSA uses made in china intel stuff with
> ME chips present for their high security stuff (hap nerfed or not), I
> imagine top secret things are done on POWER (which has a USA cpu fab and no
> black boxes).
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/29/2017 11:00 PM, taii...@gmx.com wrote:
> I can't download the .pdf file for some reason (maybe the tla's got to it?)
> http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf
> can someone send it to me?
> Thanks
> 
> 
> Thoughts:
> Sad this is still not an actual method of disablement, but it doesn't
> really matter as anyone who buys *new* x86 hardware is still supporting
> wintel's development of newer and better anti-features, DRM and
> surveillance technology - one that can't even be me-cleaner/hap/etc
> nerfed will be released some day. I wish people spent their energy
> popularizing owner controlled arches instead of beating a dead horse.
> 
> While IBM also makes surveillance tech they make POWER which as the last
> performance owner controlled arch that sells for attainable prices goes
> a long way to offset that. Heres to hoping IBM starts selling POWER
> workstations...

POWER9 workstations are already coming on the market:

https://raptorcs.com/TALOSII/

Note that IBM selling similar machines directly would likely be more
expensive, not less, based on POWER8 price comparisons between IBM and
other vendors.  People purchase IBM branded products for extreme
reliability, not to get cheap equipment...

> I find it hard to believe that the NSA uses made in china intel stuff
> with ME chips present for their high security stuff (hap nerfed or not),
> I imagine top secret things are done on POWER (which has a USA cpu fab
> and no black boxes).
> 


- -- 
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
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJZpxHDAAoJEK+E3vEXDOFbTGAH/2U1dDPoJiCIomYsD0RFox9F
O9voeIPARbsbobv6Yvl/VmAI40D81w5u/7vdk6mO//zFJXpeEpLTgytBqZlDORRV
CfnTG/etE/i8ShGgcvWCf6uqEiVdko4ng+gwh5oeQJ/WFdGlVFmeZbQ+WUwWSbr0
v6icL1SHD3EuCdNbMZimV7tcdglDEULzPHVEHSkhdMGtldWHyBvTuvp6rGAO47O4
lMM5SDXFa9S+ookTuSdLV6F3v4s4GLsmqkyPfNEWdh4iXqA72sZWAsYeyrBBn4fR
dp92uQuqgdeDr6r28YAAA8mkHD/7jbzDcDnmGiMqVyKU0ugDIlqGTvg3OsPiY24=
=C5ac
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Raphael Jacquot]

On 08/30/2017 07:06 AM, taii...@gmx.com wrote:

> Yes it is called AMD-PSP and present in the newer stuff such as AM4 and
> FM2+, although they did entertain the idea of providing a method to
> disable it in a reddit thread which a PR guy claims the CEO paid
> attention to so I suppose a corporate customer that purchases sufficient
> volume could convince them to actually do it. much better than intel's
> ignoring of the issue.

sounds more like intel designed the thing to be disabled by the NSA for
their use, but hiding the fact very well so that the same NSA are able
to use some possibly yet unknown integrated backdoor to hack into
everybody's else machines

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[taii...@gmx.com]

On 08/30/2017 12:58 AM, Philipp Stanner wrote:


Am 29.08.2017 um 20:15 schrieb Timothy Pearson:

On 08/29/2017 06:10 AM, Rene Shuster wrote:

Wow.

My favorite part is where the NSA itself basically admits that the ME
can't be trusted!  I wonder if they are looking at other architectures
or if this HAP bit was enough for their needs?


By the way: Do AMD-boards have a similar mechanism of evil?
Yes it is called AMD-PSP and present in the newer stuff such as AM4 and 
FM2+, although they did entertain the idea of providing a method to 
disable it in a reddit thread which a PR guy claims the CEO paid 
attention to so I suppose a corporate customer that purchases sufficient 
volume could convince them to actually do it. much better than intel's 
ignoring of the issue.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Philipp Stanner]

Am 29.08.2017 um 20:15 schrieb Timothy Pearson:
> On 08/29/2017 06:10 AM, Rene Shuster wrote:
> > Wow.
>
> My favorite part is where the NSA itself basically admits that the ME
> can't be trusted!  I wonder if they are looking at other architectures
> or if this HAP bit was enough for their needs?
>

By the way: Do AMD-boards have a similar mechanism of evil?



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[taii...@gmx.com]

I can't download the .pdf file for some reason (maybe the tla's got to it?)
http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf
can someone send it to me?
Thanks


Thoughts:
Sad this is still not an actual method of disablement, but it doesn't 
really matter as anyone who buys *new* x86 hardware is still supporting 
wintel's development of newer and better anti-features, DRM and 
surveillance technology - one that can't even be me-cleaner/hap/etc 
nerfed will be released some day. I wish people spent their energy 
popularizing owner controlled arches instead of beating a dead horse.


While IBM also makes surveillance tech they make POWER which as the last 
performance owner controlled arch that sells for attainable prices goes 
a long way to offset that. Heres to hoping IBM starts selling POWER 
workstations...


I find it hard to believe that the NSA uses made in china intel stuff 
with ME chips present for their high security stuff (hap nerfed or not), 
I imagine top secret things are done on POWER (which has a USA cpu fab 
and no black boxes).


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Rene Shuster]

OK, thanks for the clarification.

On Tue, Aug 29, 2017 at 4:13 PM, Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/29/2017 02:57 PM, Leah Rowe wrote:
> >
> >
> > On 29/08/17 19:15, Timothy Pearson wrote:
> >> On 08/29/2017 06:10 AM, Rene Shuster wrote:
> >>> Wow.
> >
> >> My favorite part is where the NSA itself basically admits that the
> >> ME can't be trusted!  I wonder if they are looking at other
> >> architectures or if this HAP bit was enough for their needs?
> >
> >
> >
> > So is this completely disabled, and not just "neutralized"?
> >
>
> No, it's just neutralised.  The kernel, etc. are still required to boot
> the platform, it's just that the higher level userspace components are
> disabled at runtime.  So, if a flaw is found in the kernel, etc. the ME
> remains a serious security threat.
>
> - --
> 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
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJZpcrLAAoJEK+E3vEXDOFbayIH/iZuAc88srpBSorCFJI52nya
> wGEqUUplz/VeqcxH6ojEIT1QA6qRrXOi+G7feMNiCOa83EwVjxOfpCsx5fP6WQIH
> iuIYElJiAQ+GpHAozLtMujRr0E+o/W+2iDl4CmwEKeXBydBlRwe2/EnhaktMtVy7
> LuHOH53dvGxW6m/8vPaulccbdJajBN7CYdkSFQ7gE+qEMZ0ryMq3JFXjEkgCp8vE
> cCkBDSSeVyuqar6ghf+IlLDFbLdt6FTKFmWupvL6A6Euveasq38WwGvjiUMiKGDq
> 5G9EjpAUGme2s4yiPdm2TAjvM8Sa5hlVLIw3tLa7YjcJMSYeKRPJz7VUhRVX7+k=
> =PMOh
> -END PGP SIGNATURE-
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/29/2017 02:57 PM, Leah Rowe wrote:
> 
> 
> On 29/08/17 19:15, Timothy Pearson wrote:
>> On 08/29/2017 06:10 AM, Rene Shuster wrote:
>>> Wow.
> 
>> My favorite part is where the NSA itself basically admits that the
>> ME can't be trusted!  I wonder if they are looking at other
>> architectures or if this HAP bit was enough for their needs?
> 
> 
> 
> So is this completely disabled, and not just "neutralized"?
> 

No, it's just neutralised.  The kernel, etc. are still required to boot
the platform, it's just that the higher level userspace components are
disabled at runtime.  So, if a flaw is found in the kernel, etc. the ME
remains a serious security threat.

- -- 
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
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJZpcrLAAoJEK+E3vEXDOFbayIH/iZuAc88srpBSorCFJI52nya
wGEqUUplz/VeqcxH6ojEIT1QA6qRrXOi+G7feMNiCOa83EwVjxOfpCsx5fP6WQIH
iuIYElJiAQ+GpHAozLtMujRr0E+o/W+2iDl4CmwEKeXBydBlRwe2/EnhaktMtVy7
LuHOH53dvGxW6m/8vPaulccbdJajBN7CYdkSFQ7gE+qEMZ0ryMq3JFXjEkgCp8vE
cCkBDSSeVyuqar6ghf+IlLDFbLdt6FTKFmWupvL6A6Euveasq38WwGvjiUMiKGDq
5G9EjpAUGme2s4yiPdm2TAjvM8Sa5hlVLIw3tLa7YjcJMSYeKRPJz7VUhRVX7+k=
=PMOh
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Rene Shuster]

http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf (linked in
PTSecurity's blogpost) might have the answer to your question, but it's not
accessible for me.

On Tue, Aug 29, 2017 at 3:57 PM, Leah Rowe  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 29/08/17 19:15, Timothy Pearson wrote:
> > On 08/29/2017 06:10 AM, Rene Shuster wrote:
> >> Wow.
> >
> > My favorite part is where the NSA itself basically admits that the
> > ME can't be trusted!  I wonder if they are looking at other
> > architectures or if this HAP bit was enough for their needs?
> >
> >
>
> So is this completely disabled, and not just "neutralized"?
>
> - --
> Leah Rowe
>
> Libreboot developer and project founder.
>
> Use free software. Free as in freedom.
> https://www.gnu.org/philosophy/free-sw.html
>
> Use a free BIOS - https://libreboot.org/
> Use a free operating system, GNU+Linux.
>
> Support computer user freedom
> https://fsf.org/ - https://gnu.org/
>
> Minifree Ltd, trading as Ministry of Freedom | Registered in England,
> No. 9361826 | VAT No. GB202190462
> Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK |
> Web: https://minifree.org/
>
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlmlxzoACgkQ/0W3TPnR
> z5RHPwf/TOLN0lvoyrFHZ1aj3QXCG/1pp5CmuIWU0NuEO4d2YyTyjT1NkdLzTmuG
> 1E1fNmbBN1XIciScmDPcXrccQzcwTI9LcY9Gt7E00Uf9Pxt/GkOIiaPWQN85E6NE
> KLepNuz6pSrNvYkWhVxrDe2Ft3nRflxyPbcUFNzjFz+zm7MmfoBJ0WFT7p9y6/zy
> l5LNGsiBgb/48141TzQNOF32dZUF1LGS0xrkkH7xhm2B9dnZVJjafN3tfdFmUHRw
> dONkLqN7J+cHJzfbzriNFdHWpdRhlK+urdqtTBt/UxWVF1YKjygvdZ6ONXmKLOXl
> QUOjOnstdU/oljH256ml3HSH0XhBiA==
> =UEAF
> -END PGP SIGNATURE-
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Leah Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 29/08/17 19:15, Timothy Pearson wrote:
> On 08/29/2017 06:10 AM, Rene Shuster wrote:
>> Wow.
> 
> My favorite part is where the NSA itself basically admits that the
> ME can't be trusted!  I wonder if they are looking at other
> architectures or if this HAP bit was enough for their needs?
> 
> 

So is this completely disabled, and not just "neutralized"?

- -- 
Leah Rowe

Libreboot developer and project founder.

Use free software. Free as in freedom.
https://www.gnu.org/philosophy/free-sw.html

Use a free BIOS - https://libreboot.org/
Use a free operating system, GNU+Linux.

Support computer user freedom
https://fsf.org/ - https://gnu.org/

Minifree Ltd, trading as Ministry of Freedom | Registered in England,
No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK |
Web: https://minifree.org/

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlmlxzoACgkQ/0W3TPnR
z5RHPwf/TOLN0lvoyrFHZ1aj3QXCG/1pp5CmuIWU0NuEO4d2YyTyjT1NkdLzTmuG
1E1fNmbBN1XIciScmDPcXrccQzcwTI9LcY9Gt7E00Uf9Pxt/GkOIiaPWQN85E6NE
KLepNuz6pSrNvYkWhVxrDe2Ft3nRflxyPbcUFNzjFz+zm7MmfoBJ0WFT7p9y6/zy
l5LNGsiBgb/48141TzQNOF32dZUF1LGS0xrkkH7xhm2B9dnZVJjafN3tfdFmUHRw
dONkLqN7J+cHJzfbzriNFdHWpdRhlK+urdqtTBt/UxWVF1YKjygvdZ6ONXmKLOXl
QUOjOnstdU/oljH256ml3HSH0XhBiA==
=UEAF
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/29/2017 06:10 AM, Rene Shuster wrote:
> Wow.

My favorite part is where the NSA itself basically admits that the ME
can't be trusted!  I wonder if they are looking at other architectures
or if this HAP bit was enough for their needs?

- -- 
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
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJZpa8rAAoJEK+E3vEXDOFbBv4H/RmRr8k9PFutCi9XqEamcLJy
UIrLs+XBH92AxWVQVSQH7LL+bFYCyANNkYHYpiaZ1V4lxuoDM0WVi3HdfDpCqTPV
MLklowZVrQAGPyNIW05agVh+GYTSoCWZ0fGk8IUo8j57PN/J0KWMvGjxnXQ9KFmv
I0wuFs0VrIB8IVXGf9vCw73jbr+BOW6jlTyohlk8cYIGC/i0YT1zwO88DmG+i9Qg
RqPXQ53eeSOv/JTo6NYgA8DP0JqNpbvqM+xI3irwZXw8FLg/ScPo+HNi7jl+i1yz
evBkOoDvV3ACpybtf+tB+rVlKxNs0JBqhoM5UiY58kga2Lik6/CqHMrN7p7AM8s=
=WzpR
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Rene Shuster]

Wow.

On Mon, Aug 28, 2017 at 12:08 PM, Matthias Gliwka  wrote:

> Some new development on disabling Intel ME 11: http://blog.ptsecurity.
> com/2017/08/disabling-intel-me.html
>
> Kind regards,
> Matthias Gliwka
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot