3 Qs - Intel ME neutralizing, Detect ME tampering, Statless Laptop


First I wanna thank purism for the outstanding and important work they do :slight_smile:

I have 3 Questions I hope someone can answer. Maybe someone from the PURISM team is reading and has some answers.

  1. Intel ME neutralizing
    I know that Purism is “only” deactivating the Intel ME by setting the HAP-Bit for the Librem 14. I have read the article from Positive Technologies http://blog.ptsecurity.com/2017/08/disabling-intel-me.html.
    In the “closing thought” section at the end, where they (try to) prove that the ME is truly disabled, under 2. they state that if they “remove some critical ME modules and enable HAP mode, Intel ME does not crash”.
    As I understand it, by setting the HAP bit they were able to delete modules which they could not have deleted if the HAP-bit was not set.
    So why is it not possible for PURISM to neutralize or as ptsecurity says “damage” at least a good portion of the ME code after setting the HAP-Bit?
    Wat is the difficulty? Does the newer ME require more modules to work than RBE KERNEL SYSLIB and dBUP?

  2. Intel ME tampering
    As I understand it, Purism users are pretty good equipped against firmware attacks regarding the BIOS-firmware because of the Pure Boot Bundle (coreboot, read only flash-chip and most importantly Heads).
    Is Pure Boot/Heads also able to detect ME tampering? Could you imagine a method how to detect tampering which e.g. was conducted by reflashing/reactivating the ME?
    To my knowledge a small portion of the ME is on the CPU-ROM storage but most of the ME is stored in the Flash-Chip (SPI) next to the BIOS.

  3. A question regarding Joanna Rutkowskas’ idea of a stateless laptop (https://blog.invisiblethings.org/papers/2015/state_harmful.pdf). She is talking about having a “trusted stick”. However, her main point, as I understand her, is a read-only firmware partition, either read-only (SPI)-chip or just a USB-stick etc. So I would rather call it “Read-only (firmware) laptop”.
    I know that it has been a topic in this forum a few times.
    I would just like to know from a Purism member (hopefully one is reading this) if it were possible to implement the idea and how hard it would be for Purism / a manufacturer to do it? Do you think the Intel ME would work with read-only firmware, i.e. read-only SPI or the like?
    Could you design such a Chip, let it be manufactured and flash the ME on it? Which of these steps would be the most difficult/impossible?
    The disadvantages of a read-only SPI would be that you cannot update anything, right? This must be one of the reasons why Joanna is proposing a external user device with read/write toggle.

1 Like

As I understand it, there is some sort of table of contents in Intel ME for all the modules it loads. The way it used to work was that each module was signed, but the table itself wasn’t. This allowed removal of ME modules by simply eliminating those entries from the table and then overwriting the module data with zeroes to be extra sure it could not be loaded. In the newer version, the table itself is also signed so that is not longer possible.

Thanks for your answer!

that article is about ME 11. We do clean/neutalize ME 11 on the Librem 13/15. ME 12 has a completely different structure to the firmware, one which does not lend itself easily to removing unused modules. More work is needed in order to be able to clean/neutralize ME 12

we can/do on the Mini v1/v2, since those are TPM-less and the entire SPI flash chip is hashed, including the IFD and ME regions. On the L14, although we don’t directly measure the ME firmware region, any changes to the IFD/ME to reactivate it would affect the TPM measurements done by coreboot and would be flagged as potential tampering

there’s a lot of reasons why the firmware can’t be RO, none of which involve the ME. The biggest one is RAM training – the optimization routines calculated on the first boot after flashing, or any time the RAM is changed – which takes ~30s on a modern Intel platform. If you can’t save that data somewhere, then you’re adding 30s every time you cold boot the device. Then there’s an issue of user control/ability to update.

While some external firmware stick with a RO/RW toggle on it sounds like it would solve those, SPI doesn’t lend itself to long traces or an external dongle type interface – all of these things have been looked at, and were it practical to do so, someone would have.