Using HAP to disabling ME, does not disable or limit BootGuard.
It disables CSME, which is responsible for Boot Guard (p9), so it would disable it.
1 Like
What is disabled?
If you use HAP ME will run the boot sequence and then shut down, ME will read the key for BootGaurd.
Donât see how that would work, when the key for BootGuard provides the key, and the CPU trusts the key given to it from the PCH.
Iâm not sure what you are saying, but you canât just enable HAP and bypass BootGuard. If that was the case, you could run Coreboot and any Intel laptop, which you canât.
HAP doesnât prevent ME from starting, all it does is to tell ME is shut down once the bring-up routes have completed.
1 Like
It doesnât bypass it, you just have nothing to begin with, no hardware based root of trust at least that is my understanding from the docs. CSME is required for that checking to occur.
Do those Linux laptops use BootGuard to check to see the Coreboot BIOS is authentic?
Also looking at that document again, it indicates that some of it would need to be still running so you can use TXT.
@dngray you might be interested in reading Disabling Intel ME 11 via undocumented mode if youâre wondering about what the HAP bit affects in the boot process and when. It doesnât disable (CS)ME entirely (like I said in November) like you are claiming, and shouldnât disable Boot Guard.
Anyways, the problem with Intel ME is that it runs an operating system (MINIX) on your computer at all times which:
- You cannot update yourself. We cover the benefits of regular security updates to your operating system constantly here, so the inability to do so here shouldnât need further explanation.
- Relies entirely on security through obscurity, which is obviously not and has never been good security practice.
There is no world where it makes sense to hide management functionality from the user, and I think the only reason they still do is indeed because of Hollywoodâs demands for DRM and that the DRM protections be hidden.
If Intel ME was open source, and people could build and install it with their own keys, it wouldnât actually be an issue. Intel ME enables some useful functionality. This is how virtually all other important security mechanisms work (e.g. Secure Boot), and thereâs no reason Intel ME should be any different.
All of this wonât matter for long because x86 is basically a dead man walking at this point 
4 Likes
You know the ME and BIOS flash regions have not been modified, itâs simply not possible with BootGaurd enabled, regardless of HAP being enabled.
HAP works because it is located in the Intel Flash Descriptor region, which you can modify without changing the ME or BIOS firmware.
Linux/Coreboot laptops use vboot, at least some do, which does the same thing as BootGuard. The big different is that vboot uses a write-protected flash region, that could be overwritten by an attacker with an eprom programmer and physical access to the device.
This post indicates that if the user can set the HAP bit, the field descriptor isnât locked, and it will fail even HSI 1.
To pass HSI 1, the field descriptor has to be locked. I have also not found any documentation saying that if the manufacturer sets the field descriptor to 1 then lock the field descriptor, Boot Guard still isnât broken. Tools like fwupmgr definitely will report that Boot Guard isnât active though, because CSME registers cannot be read at all.
Another thing that comes into my mind: Even if you somehow keep Boot Guard when setting the HAP bit, and the ME will turn itself off after the computer has booted up - the UEFI capsule for firmware updates will be broken. How exactly is this reducing the attack surface? You are just breaking firmware updates now.
@Jonah The ME does get firmware updates. The whole point you made about open sourcing the ME doesnât make much sense.
The closed source nature of the ME has nothing to do with key enrollment. The key is written to a one time programmable fuse. Even if it was open source, the user wouldnât be able to replace it. If it was proprietary, if users get access to PCHs without the key fused in, they can enroll their own key in.
Secure Boot is meaningless without Boot Guard. This is why at minimum you need to pin against PCR 7. Because the assumption here is that the firmware is truthfully reporting secure boot state. This only possible because BootGuard provides an immutable root of trust verifying the firmware integrity. Otherwise an attacker can just disable Secure Boot or change what is trusted with a programmer. Similar logic applies to Pixel too - you can only trust the custom key enrollment for the OS because there is an immutable root of trust verifying that the firmware is from Google.
I donât really understand why youâre making this a very complicated topic. Itâs actually very simple, when you buy a computer you have the choice between:
- A computer that runs a proprietary OS in the background you have 0 control over, which has full control over said computer, which has network capabilities so it is inherently always a security risk, and which is considered a risk by virtually all security experts who have voiced an opinion on the topic.
- A computer that doesnât have that.
Answer is pretty simple, and I think has been explained to death in this topic by now anyways 
so I will just unsubscribe from this thread and move on.
3 Likes
The networking capabilities are a part of AMT and can be disabled. You can also permanently disable them by blowing fuse, same with Computrace for example (Config â Intel(R) AMT â Intel(R) AMT Control).
The only time you canât is if itâs provisioned, and that then means itâs not your computer (probably your employerâs).
1 Like
Well, almost all hardware is proprietary and so is a lot of firmware. So having another proprietary part does not really leave me worried.
Since disabled AMT is the default on most devices anyway, do you have expert opinions which weigh the benefits and problems of Intel ME, with disabled AMT?
1 Like
What features are you missing if you disable ME, by enabling HAP?
As fare as I can tell, Boot Guard, Secure Boot, and Total Memory Encryption all work just fine with HAP enabled.
I personally donât use any of the ME specific features, but I presume WOL, wake-up timers, remote KVM if you have AMT, etc. all stop working.
Worth noting that Google Chromebooks can be corebooted with firmware from MrChromeBox and it represents a low cost way to get a corebooted laptop, especially as schools often use chromebooks for a couple years and then donate them to recyclers. Usually they are low spec, and I have had two of mine get unrecoverable corruption of some kind, but its good for experimenting with coreboot.
I donât think AMDâs PSP has a network stack, does it? Wouldnât AMD be the easiest choice then?
Boot Guard
Do you have any docs anywhere confirming this? Which Boot Guard feature still actually work, eg:
- Boot Guard Verified Boot
- Boot Guard ACM verification
- Policy enforcement
Are there any actual computer with the HAP field disabled and the descriptor/CSME manufacturing mode locked and a dTPM? This is important because the fTPM wouldnât work anymore.
Secure Boot
This depends on Boot Guard working so if Boot Guard doesnât work properly then itâs not going to be useful.
Total Memory Encryption
TME-MK is not directly dependent on CSME, so it may work. Can you provide something to confirm this?
Edit: Iâve now read that article Disabling Intel ME 11 via undocumented mode mentioned in the above post. The author is quite clear at the end:
But the main question remains: how does HAP affect Boot Guard? Due to the closed nature of this technology, it is not possible to answer this question yet, but we hope to do so soon.
They do, have OOB eg DASH. These things are only available on enterprise-grade hardware though, same as Intel.
3 Likes
Of course, but proprietary hardware and firmware is exactly the problem in the first place
sha123âs point is that disabling IME would be an insufficient countermeasure against a hypothetical where Intel is malicious. Youâre running an Intel CPU whose firmware is not open source. If Intel was malicious, the CPUâs malicious firmware would be sufficient to compromise your system.
Supposing that Intel is not malicious, disabling IME disables various protections which have been mentioned in this thread.
3 Likes
Iâm just pointing out that itâs shifting goalposts within this overall thread. The original discussion has always been about if Intel ME is bad, which it is.
Now weâve shifted to talking about why it is bad to disable Intel ME, which is a different topic that has nothing to do with what this thread was even about in the first place. And furthermore, sha123 is now talking about disabling AMT for some reason, which is yet another entirely different feature that is not Intel ME, just a subset of it. AMT is not the only component of Intel ME which could access the network, it is simply the only component of Intel ME that you can access via the network, so dngray was simply incorrect about that. Intel ME has unrestricted access to all hardware in the system, including e.g. your network cards (obviously).
They can read https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf (p34-39) if they want to know the difference between Intel AMT and Intel ME, and the general security concerns with Intel ME (which again, would apply regardless of AMT status). There have been plenty of vulnerabilities in Intel ME both with and without Intel AMT enabled.
So all Iâm saying is the discussion has kind of gone off the rails, but I think itâs run its course.
1 Like
If we agree disabling IME is bad because of its security features, itâs clear those security features make IME good in the context of our discussion.
2 Likes