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] coreboot support for Minnowboard Turbot E3845

[Piotr Król]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 12/13/2017 07:29 PM, Michael Graichen wrote:
> Hey,

Hi Michael,

> 
> I've bought a Minnowboard Turbot (quad core / E3845) to start
> developing on the Atom's.
> 
> I was hopping that it has support like the Minnowboard Max but it
> get stuck right after FspInitApi(); in 
> coreboot/src/drivers/intel/fsp1_0/fsp_util.c. The last output i can
> see is "POST: 0x92" which comes from
> post_code(POST_FSP_MEMORY_INIT); right before
> FspInitApi();

I'm not expert in MinnowBoard Turbot, but I play recently with E3826
and saw similar behavior when incorrect microcode was used (or no
microcode). What are your ucode configuration ?

Best Regards,
- -- 
Piotr Król
Embedded Systems Consultant
https://3mdeb.com | @3mdeb_com
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAloxsggACgkQsu5x6Weq
nkzfPg/+PM8fk80pbmexWQw5IO4LbDOX4vw5LYkrkeTxh/3T6hAAjBt7KJ6OA4Ft
vW8d/Ll37/r7zutrOXemXZRtxulHy4FL/7aGcDdu8JPxnO4ysLGM0fOZxkZtuyNA
WYI7nS5mYcVdA69driI3rW0cSuGVAy7LiOBIzzV5Z8iWjQXop56cMJiP6In7zayr
7B5XZ6Ix934AzYihK6hZ5Rz5jZyouKb0NJRQLnRB+MljuL4sLa18bnX5NUBqgDxu
cbw54UYgkgd6CsrbGw3XIGB63k7jYYOUayZwBaqg4QYIxPs798pX5MTe7VMJneFc
kmg+t8HHZxQkaF9YjoVwyS5y4/24FgwQ5bROo/ztNqZMz2q0nK6jd7vQjobFKTVb
Hc7w0jQIY37z3ZConHj9hHeVQ4AILFgpUl+NJj04hekcs4aAwJhbMun7YEAmchkp
cCsv+WvXmOUZwTZR+CoH1xTYSMIX6JkMDZlmlhR/UGlAdpIkxMKQ6MezJXgyihvn
rBBAMDKGvNxeZ00Cf35d+tI9OwDWw/YxYDMV3nx5MzeIkvho4Umg6ey824QlqxBF
D+3wYuiB4ZO/uEViYkW62jFOMHxeTZ9lBNdigPsnuclDiXhvAoA1uImsaLHjNHpQ
xndtfh+FPE3kB6c4koorgXxa3OZacd+4pGDmyjOy7Vl+TZk5hkA=
=r1Ls
-END PGP SIGNATURE-

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

[coreboot] coreboot support for Minnowboard Turbot E3845

[Michael Graichen]

Hey,

I've bought a Minnowboard Turbot (quad core / E3845) to start developing 
on the Atom's.

I was hopping that it has support like the Minnowboard Max but it get 
stuck right after FspInitApi(); in 
coreboot/src/drivers/intel/fsp1_0/fsp_util.c. The last output i can see 
is "POST: 0x92" which comes from post_code(POST_FSP_MEMORY_INIT); right 
before FspInitApi();

 From FSP it should return to 
src/soc/intel/fsp_baytrail/fsp/chipset_fsputil.c ChipsetFspReturnPoint 
but i never gets here.

So far I've tried Minnowboard Max config and bayleybay_fsp both with the 
same result.

I'm using Minnowboards original Firmware and overright the las 3MB with 
coreboot.
As FSP I use the branch BayTrail from https://github.com/IntelFsp/FSP

Am I missing something to make it boot?

Is anyone booting coreboot on the Turbot?


Best Regards,

Micha




-- 
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] Lenovo G505s AMD Hardware Virtualization

[taii...@gmx.com]

Congratulations for following through on the investigation :D

I am not sure how to do a commit, but I hope you are able to find out as 
you will have helped a lot of people.


I am pleased with myself for noticing that the lack of microcode updates 
was the issue - as the CPU is similar to a piledriver not a bulldozer it 
requires microcode for IOMMU.


I do not have the technical documents for that chipset and I do not know 
how to change the PCI regs but I am sure the USB controllers support FLR 
considering the nearly identical SR56xx chipsets usb controllers do - I 
will look in to this further.


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

Re: [coreboot] Is Goryachy's JTAG hack a chance for free firmware ?

[Denis 'GNUtoo' Carikli]

On Wed, 29 Nov 2017 23:39:27 +0100
"Enrico Weigelt, metux IT consult"  wrote:

> Hi folks,
> 
> i'm curios whether Goryachy's JTAG hack is a chance for
> getting rid of all proprietary ME/UEFI firmware.
> 
> If i'm correct, the ME firmware (or parts of it) is signed, and
> the CPU won't run (or switches off) if signatures don't match.
> 
> Can the JTAG channel be used to get around that ?
We don't have enough information on that yet to understand if it's
possible or not.

More precisely, I don't know:
- If it's possible to halt the Management Engine (trough the JTAG)
  before it starts executing code, load code for it to execute, and
  make it execute that unsigned free software code that would
  initialize enough hardware to make the computer start.
- Or if it's possible to halt the Management Engine and instead
  initialize that hardware trough the JTAG.
- If it would be possible to use another computer and an USB3 controller
  that don't depend on non-free software to initialize a recent Intel
  system without depending on any non-free software.
  It would be nice to be able to use A Rockchip SBC with USB3, or an
  SBC with a free software bootloader and with a PCIe interface and a
  PCIe USB3 card to do that.
  If this is possible it would enable building a desktop or server
  computer that can start with free software. The SBC could also be
  used to run some tasks while the main computer is off, such as an IRC
  client or server software.
  However If getting JTAG trough DCI requires a skylake computer, then
  there is a chicken and egg problem...

Denis.


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

Re: [coreboot] Can't disable CONFIG_ENABLE_FSP_FAST_BOOT flag on Intel Baytrail platform

[Naveed Ghori]

Nico,
I faced this same thing earlier I believe.
The reason I disabled it was to stop coreboot from writing to the flash chip. I 
was advised to turn off CONFIG_ENABLE_FSP_FAST_BOOT and this worked for the 
flash but had this side affect.

Garrett, Are you disabling it for the same reason?

Regards,
Naveed

-Original Message-
From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Nico Huber
Sent: Wednesday, 13 December 2017 2:12 AM
To: GARRETT DOORENBOS; coreboot@coreboot.org
Subject: Re: [coreboot] Can't disable CONFIG_ENABLE_FSP_FAST_BOOT flag on Intel 
Baytrail platform

Hello Garrett,

On 11.12.2017 18:16, GARRETT DOORENBOS wrote:
> I'm running coreboot on an Intel Atom Bay Trail based platform. When I 
> turn off the CONFIG_ENABLE_FSP_FAST_BOOT flag, I get stuck in the 
> Intel FSP (it never returns) after a warm boot. The only way around it 
> is a power cycle. Has anyone seen this before?

AFAICS, the Bay Trail FSP doesn't have such an option. So it might be the case 
that the binary always expects a non-volative cache. But that is disabled in 
coreboot if you disable ENABLE_FSP_FAST_BOOT (by chance).
Intel is known to present options where only one value works.

The correct solution seems to be to always `select ENABLE_MRC_CACHE` for 
fsp_baytrail and remove the related guards in its code. And hide 
ENABLE_FSP_FAST_BOOT for fsp_baytrail because it just doesn't apply.

May I ask why you want to disable fast boot?

Hope that helps,
Nico

> Hello,
> 
> 
> Thanks,
> Garrett Doorenbos
> Software Engineer - Almost Hardware
> 
> Office: 256.963.6369
> Email: 
> garrett.dooren...@adtran.com
> Web: 
> https://linkprotect.cudasvc.com/url?a=https://www.adtran.com=E,1,zia
> _2uPTk6eMKH9gxkBHCoibI9nwJEX2LFUylJISwIdygIKxKW7m9UY_xFRaUZNXqWJbsPdXa
> zGCnP8yadglsZ-8otIfNn5reQKUZwil-62tbqBxWi6O=1 .cudasvc.com/url?a=http://s.bl-1.com/h/CoY1mz9%3furl%3dhttp://www.adtr
> an.com=E,1,beG-szik-KkZHDBsYBUzzoYyR9r5_94FiWhrk0r_Jz7lqTwQtZS9QP3Bp
> NWye1btciSTvOOYIxQVfV-GDtWIzNVSVkhXlNoT7wIQGQEtnw,,=1>
> 
> ADTRAN
> 901 Explorer Boulevard
> Huntsville, AL 35806 - USA
> 
> [ADTRAN] 1mz9%3furl%3dhttp://www.adtran.com=E,1,ihpsTD49cQZcEW4B_7z9R-e0pweJL
> hZ2Jc7tv8TAZgScBYpApgkTONb1FlsLlksahwDapvtGPkUDoCG6M4ntljQ71glwSRSrrHL
> xu6IHzg,,=1>
> 

--
coreboot mailing list: coreboot@coreboot.org
https://linkprotect.cudasvc.com/url?a=https://mail.coreboot.org/mailman/listinfo/coreboot=E,1,8sPT2uh_yHod8AcND0FP1z0oCyb0lpkZ10j1lO1TGpzfy-rY4qIjdF-KHnt6SjfhgvaE2BbEIKMymatJ4YixfDRNr6XH3wMPOHeueOLvj4PmGxjeUb2gpQ,,=1

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

Re: [coreboot] Hardware vendors offering systems with Intel ME disabled

[Denis 'GNUtoo' Carikli]

Hi,

On Thu, 7 Dec 2017 22:29:44 +0100 (CET)
eche...@free.fr wrote:
> [...] to this new initiative of Dell or System76?..
For Intel devices with chipsets more recent than the GM45, so far I
know only the following manufacturers that "disables" the Management
Engine:
- Puri.sm which enables the HAP bit and runs me_cleaner to remove
  unneeded ME partitions.
- System76 which "Disable" the Management Engine (how?).
- Dell that "Disables" the Management Engine too (Trough HAP?).

Are there more, and is there more information on how system76 does it.

Denis.


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

Re: [coreboot] Hardware vendors offering systems with Intel ME disabled

[Denis 'GNUtoo' Carikli]

On Thu, 07 Dec 2017 16:22:48 -0600
Timothy Pearson  wrote:

> While dell has not gone into detail on this offering, from what has
> been described it is highly likely that they were setting the HAP bit.
I would guess that too, especially since Dell was already part of
the High Assurance Program (HAP)[1].

However do we have more concrete information on it, did people run
intelmetool or dumped the flash to understand if me_cleaner was used on
it or not.

Reference:
--
[1]http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf

Denis.


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