This model seems to be as opened as far as possible, though (https://libreboot.org/docs/install/t480.html):

One of the benefits of deguard for Intel MEv11 is that it sets the ME in such a state where you can run unsigned code in there. This is how the Intel Boot Guard was disabled, because it is the ME that enforces such restrictions; more information about deguard is available on a dedicated page.

The deguard utility could also be used to enable the red-unlock hack, which would permit unsigned execution of new CPU microcode, though much more research is needed. Because of these two facts, this makes the T480/T480s the most freedom-feasible of all relatively modern x86 laptops.

With deguard, you have complete control of the flash. This is unprecedented on recent Intel systems in Libreboot, so it’s certainly a very interesting port!

>It is not possible for 3rd parties to disable Intel ME. Nobody but Intel themselves can disable ME.

...Dell? I have multiple of their machines which have been configured via their B2B panel to have ME fully disabled.

HAP disables the ME's runtime interface, it doesn't prevent the ME from booting.

Depends on how you define "booting". While its true that the microkernel always boots, and there is one userspace process running, it's a bit more subtle than that imo.

The bringup module always boot which configures the clock controller, bootguard parameters, and releases the CPU core from reset. When in HAP mode, after that it only handles power management events and doesn't really do anything else. No other ring 3 processes are started on the ME in this mode.

Stuff like even the real read-write VFS, fw updater, HECI comms handerl, AMT, PAVP, ISH server, etc are never started in HAP mode. It effectively reduces your runtime attack vector to data in SPI flash only.

> Depends on how you define "booting".

As mentioned in one of the linked tweets, ME was possible to exploit through early-boot attacks before the HAP bit was even checked. So non-negligible things happen while it "boots".

Absolutely is, one of those exact attacks is being used here to bypass BootGaurd. However all pre-boot attacks I am aware of rely on writing a malicious payload to the system's SPI flash and involve physical access.

While they are genuine vulernabilties, I wouldn't consider this a worse problem than being able to inject rootkits into other parts of the firmware which is also the case here.

In my understanding, the concern is not what outside attackers can do. It is what capabilities exist under Intel's control before they are reduced to some hopefully benign subset.

And the understanding that we have is mostly limited to what is in flash memory, e.g. the ME's BootROM hasn't been dumped yet (as far as I am aware).

I have the ME11's boot ROM in a disassembler as I write this :)

I wrote the deguard utility that made this possible. (The vulnerability being used was found by PT Research in 2017 however.)

While yes you cannot strictly disable the ME, what remains of its firmware in this configuration is a bringup module that is stuck in a loop handling power management events.

The network stack, HECI stack, etc are all gone here. Effectively the only way to exploit it is to put your payload into SPI flash, which we are already doing anyways :)

It is also possible to take over the ME firmware and bring up the CPU using open source code, and have full control over the ME at runtime. This isn't implemented currently, but that's the direction this is aiming in.

Just wanted to say thanks for your contribution to making this stuff possible :) fist bump

> The network stack, HECI stack, etc are all gone here.

I think there is a misunderstanding. Intel ME is a hardware feature. Yes there is some flash memory which contains more code and an operating system, but what is stored in flash memory is only part of Intel ME.

Peter Stuge from Coreboot noted during his 30C3 talk that even if you completely zero out the flash, it is possible for Intel ME to send a network packet out of the ethernet interface. The cutoff point when this started happening is the 965 chipset around 2006.

https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271... (relevant part starts at 17:19)

It is a hardware feature, but it does basically nothing without its software in flash....

The only code that is inside the silicon is a 128K bootrom that literally just sets thing up for the real firmware to run.