Discussion on Purism

[ubersecure]

@Justin

One last quote from Thierry (@Insurgo) from almost five years ago, may be worthy of inclusion:

“Neutralizing/Deactivating/Deleting/Freeing Intel ME is a word game
where a lot of ink spilled over the last years. I suggest you to read
this doc: How does it work? · corna/me_cleaner Wiki · GitHub
Basically, Intel ME version <11 can be deactivated, since no kernel
needs to be present in the firmware for validation prior to initialization,
resulting in the BUP module only being launched, permitting the machine
to boot, where version >11 requires the kernel and syslib modules to be
present and validated at initialization. So even if Intel ME is neutralized by
me_cleaner, the modules are still there in >11. Could they be executed?
That depends on your beliefs and threat modeling.”

Emphasis added.

@Insurgo corrected that quote in his next post:

" Sorry to have misadvertised Purism work. Didn’t went across that post: Neutralizing the Intel Management Engine on Librem Laptops – Purism

So it seems that Intel ME deactivation is on par with Ivy bridge, resulting in only the ROMP and BUP modules being required to initialize ME.

For firmware binary blob requirements, FSP is still required, see here: https://github.com/osresearch/heads/tree/master/blobs/librem_skl and here https://github.com/osresearch/heads/blob/master/config/coreboot-librem13v2.config"

Perhaps @Insurgo or someone else more knowledgable than me can clarify how that affect the question Could they be executed?

[Justin]

@ubersecure

So it seems that Intel ME deactivation is on par with Ivy bridge, resulting in only the ROMP and BUP modules being required to initialize ME.

Appreciate you sharing your research. My understanding, admittedly limited and likely out of date was that the ME kernel and syslib modules (and probably more) are still present in the Comet Lake based Librem 14. Would love to learn that I’m wrong and the Comet Lake ME situation is, as you say, “on par with Ivy bridge”.

@ubersecure

For firmware binary blob requirements, FSP is still required,

IMO that’s quite unfortunate but not surprising. Thanks again for sharing your research @ubersecure

@ubersecure

Perhaps … someone else more knowledgable than me can clarify how that affect the question Could they be executed?

+1
I also would be interested in reading and learning more about this.

[Insurgo]

Tried to have bing understand the differences prior of posting outcome below (still imperfect. Confusion still present but lowered)

Model	Processor Generation	Codename	Example highest end CPUs	ME Deactivation	ME Neutering	ME Removal	Qubes Support
Librem 13 v1	5th	Broadwell	i7-5557U	Yes	Yes	No	Yes
Librem 13 v2	6th	Skylake	i7-6500U	Yes	No*	No	Yes
Librem 13 v3/v4	7th/8th	Kaby Lake/Coffee Lake	i7-8550U	Yes**	No*	No	Yes
Librem 14 v1	10th	Comet Lake	i7-10710U	Yes**	No*	No	Yes
Librem Mini v1/v2/v3	8th/10th/11th	Coffee Lake/Tiger Lake-U	i7-1165G7	Yes**	No*	No	Yes
ThinkPad X200/T400 etc	Centrino 2/Centrino vPro/Centrino vPro2/Centrino vPro3/Centrino vPro4/Centrino vPro5/Centrino vPro6/Centrino vPro7/Centrino vPro8/Centrino vPro9 (modded)	Penryn/Cantiga/Montevina/Montevina Plus	Core 2 Extreme QX9300/QX9400/QX9500/QX9600/QX9700/QX9800/QX9900 (modded)	No*****	No*****	Yes******	No
ThinkPad X230/T430/W530 etc	3rd	Ivy Bridge	i7-3612QE (modded)	Yes	Yes***	No	Yes
*Neutering is not possible for these chipsets because they require other modules then BUP/BUP+ROMP to be present and signed in the ME firmware. Those include kernel, Java runtime and policies to be in signed digest validated at ME platform initialization and cannot be removed.
**Deactivation is possible for these chipsets, but requires a newer version of me_cleaner or coreboot that supports the ME 12 firmware.
***Neutering is possible for these chipsets by removing all modules except BUP and ROMP.
*****Deactivation and neutering are not possible for these chiosets because they use an older version of ME (ME6 or lower) that does not support the HAP bit or me_cleaner.
******Removal is possible for these chipsets because they do not have the hardware checks and dependencies that require the ME firmware to be present and valid on the system. This can be done by using coreboot or libreboot as the firmware.

As you can see, the Librem models have ME deactivation and Qubes OS support, while the ThinkPad X230 models have ME deactivation and neutering, and also Qubes OS support. The ThinkPad X200 models can remove ME entirely, but they do not have ME deactivation, neutering or Qubes OS support.

Source: Conversation with Bing, 16/10/2023
(1) Lenovo ThinkPad X200 Review | Laptop Mag. Lenovo ThinkPad X200 Review | Laptop Mag.
(2) ThinkPad X series - Wikipedia. ThinkPad X series - Wikipedia.
(3) Lenovo ThinkPad X200 review: Lenovo ThinkPad X200 - CNET. Lenovo ThinkPad X200 review: Lenovo ThinkPad X200 - CNET.
(4) ThinkPad X230 Product Specifications Reference (PSREF). https://psref.lenovo.com/syspool/Sys/PDF/withdrawnbook/ThinkPad_X230.pdf.
(5) ThinkPad X230 Product Specifications Reference (PSREF). https://psref.lenovo.com/syspool/sys/pdf/withdrawnbook/thinkpad_x230_we.pdf.
(6) Lenovo ThinkPad X230 review: Lenovo ThinkPad X230 - CNET. Lenovo ThinkPad X230 review: Lenovo ThinkPad X230 - CNET.
(7) Purism– Librem 5. Purism– Librem 5.
(8) Purism– Products. Purism– Products.
(9) Librem 5 - Wikipedia. Librem 5 - Wikipedia.
(10) Librem - Wikipedia. Librem - Wikipedia.

---

After two hours or so clarifying and making certain Bing understands the whole confusion about terminology :

I’m sorry for the confusion. I have searched the web for more information about ME deactivation, neutering and removal, and I have revised my knowledge and answers accordingly. Here is what I have learned:

• ME removal: This is a method that completely removes the ME firmware from the system, leaving no trace or functionality of it. This method would be ideal for users who want to have full control and transparency over their system, without any proprietary or potentially harmful firmware. However, this method is only possible for some older processors, such as Penryn and Yonah, that do not have the hardware checks and dependencies that require the ME firmware to be present and valid on the system. If the ME firmware is missing or corrupted, the system will either not boot at all or shut down after 30 minutes. This method can be done by using coreboot or libreboot as the firmware. This method was discovered by the libreboot project.
• ME deactivation: This is a method that uses a special bit in the ME firmware called the HAP (High Assurance Platform) bit. This bit was originally intended for government use, to disable ME functionality for security reasons. By setting this bit to 1, the ME firmware will stop running after the hardware initialization phase, effectively deactivating most of its functions. However, this method does not remove or modify any code or data from the ME firmware, so it is possible that some residual functions may still be active or that the HAP bit may be reset by a malicious actor. This method is supported by some tools, such as me_cleaner and coreboot, and it works for most Intel processors from Sandy Bridge to Kaby Lake. This method was discovered by Positive Technologies, who found a way to use the HAP bit to disable ME without triggering any errors.
• ME neutering: This is a method that goes beyond deactivation and tries to remove or modify as much code and data from the ME firmware as possible, without breaking the system. This method aims to reduce the attack surface and the potential harm of ME, by eliminating unnecessary modules and features. However, this method is not always possible or safe, as some parts of the ME firmware are essential for the system to boot and function properly. For example, some processors, such as Sandy Bridge and Ivy Bridge, require a module called BUP (Bring Up) to be present and signed in the ME firmware, otherwise the system will shut down after 30 minutes. This module can be kept in the ME firmware, while other modules can be removed or modified, resulting in neutering. This method is also supported by some tools, such as me_cleaner and coreboot, and it works for some Intel processors from Sandy Bridge to Broadwell. Neutering is when BUP and ROMP are required but kernel and other modules are signed and cannot be removed. This method was discovered by Trammell Hudson, who found a way to use an undocumented “AltMeDisable” bit to disable most of the ME functions after booting.

---

I think the confusion lies within revisions of same models. Librem existed across multiple chipset revisions. Their model labeling is in regard of screen size, not necessarily chipsets.

Bing answers correctly

You are right, the Librem models are labeled by screen size instead of chipset revision, which can cause some confusion. According to the coreboot firmware page², the Librem 13 v1 has a Broadwell processor, which supports ME neutering. The Librem 13 v2 has a Skylake processor, which does not support ME neutering. The Librem 13 v3 and v4 have Kaby Lake and Coffee Lake processors, respectively, which also do not support ME neutering. The Librem 14 v1 has a Comet Lake processor, which does not support ME neutering either. The Librem Mini v1, v2 and v3 have Coffee Lake and Tiger Lake-U processors, which do not support ME neutering as well. The only Librem model that supports ME neutering is the Librem 13 v1. All the other models can only deactivate ME using the HAP bit. I hope this clears up the confusion.

Source: Conversation with Bing, 16/10/2023
(1) Coreboot Firmware on Purism Librem Devices – Purism. Coreboot Firmware on Purism Librem Devices – Purism.
(2) Librem 5 Hardware - Phones (Librem 5) - Purism community. Librem 5 Hardware - Librem 5 - Purism community.
(3) Librem 5 Phone – Birch - Purism. Librem 5 Phone – Birch.
(4) undefined. Librem 5 Phone – Evergreen.

Here again, note that this applies to chipsets and not models.

My attempt to clarify this is still at the same place as always, referred multiple times at Platform blobs, collaborators/maintainers/testers for faster problems resolution · Issue #692 · linuxboot/heads · GitHub

Edit: multiple in link of core 2 duo, neutering/deactivation/removal of ME legend.

[fsflover]

Thank you @Justin for your kind words.

@Justin

The main problem, as I see it, is oversimplification.

I disagree that oversimplification is a problem. It would only be a problem if you had few possibilities to dig deeper, like with Apple, but in fact Purism usually provides all links and detailed technical explanations. (It’s like saying that new terms should never be invented to simplify speech, because they “can be misleading to someone truly concerned”.) I think that new terms make it easier to talk, if done well and transparently, which is the case here, see also below.

@Justin

For instance in link we both referred to, the author states that “disabled” is “…the
ME is officially “disabled” and is known to be completely stopped and non-functional”.

On the one hand, I agree with you here: “completely stopped” and “non-functional” are misleading. Since beginning of time, Purism oversold their work with too much hype. (So I’ve been always checking what they actually do, and I’ve been in general satisfied with less.) Of course, as far as I understand, disabling means you only “ask” Intel ME to switch off and must trust it to obey.
On the other hand, NSA and co. must have a method to close this backdoor for themselves, and indeed it was eventually discovered, without official disclosure. The latter makes it actually more trustable in my view, since Intel definitely doesn’t want you to tinker with Intel ME, but they likely had to provide a way to disable to “appropriate” users. So in the end, it’s quite likely (despite unverifiable) that Intel ME is actually deactivated, or disabled by it’s own will. This is exactly how I understand this:

@Justin

the HAP bit soft-disable strap method
is “official”

@Justin

It seems strange to me that someone who does not trust
Intel’s Management Engine would trust Intel’s HAP soft-disable bit flip.

I hope I clarified above that the “official”, from the point of view of the ME software itseld, way of disabling the code gives us a good reason to trust that it works, as long as Intel did not expect that users knew about this possibility. I could be mistaken, but I think it’s the case. If not, it could be a trap of course.

Concerning the new, useful definitions, consider this post by me_cleaner: They provide two different ways to fight with Intel ME but call them by the same name “Disable”. Later, with the new generation of Intel CPUs only one approach still works but the name stays the same, and people, like you or c0d3z3r0, start to ask reasonable questions like “how can this be true if it’s impossible?” Indeed we can’t do half of it now.

The other part, which is called “neutralize” by Purism, sounds very appropriate to me, too, since it very well reflects that this is action goes against the ME’s own plans, which is true.

@Justin

to illustrate why I think purism’s “invented” terminology and
oversimplification could be misleading to someone truly concerned about
Intel’s ME.

To repeat, in my opinion, the real reason for the misunderstanding in your quotes/links comes from the misleading original me_cleaner’s definition, which doesn’t distinguish two very different cases.

@Justin

I’ll risk veering off-topic to respond.

It won’t be off-topic, if I move it to the appropriate place, which I just did.

@ubersecure

Librem 14 has an Version 12 ME. Not sure if that means you got yours before then?

Yes, I daily drive a Librem 15.

@ubersecure That update by @Insurgo was correct, but it was written before Librem 14 was released (in 2020). I think Purism say sufficiently clearly that ME in Librem 14 is “only” disabled but not neutralized. What is unclear with it?

[fsflover]

Thank you @Insurgo for the nice table. However, I believe it’s not very accurate.

@Insurgo

Librem 13 v2

@Insurgo

Librem 13 v3/v4

@Insurgo

No*

I am not sure that this is accurate, see this and this:

@kakaroto

2017-10-12: The script now neutralizes and disables the Intel ME

@kakaroto

It will first ask you if you want to build it for Librem 13 v1, Librem 13 v2, or Librem 15 v1/v2 or Librem 15 v3

Also, there is no Librem 15 in the table.

@Insurgo

(7) Purism– Librem 5. Purism– Librem 5.
(8) Purism– Products. Purism– Products.
(9) Librem 5 - Wikipedia. Librem 5 - Wikipedia.

@Insurgo

(2) Librem 5 Hardware - Phones (Librem 5) - Purism community. Librem 5 Hardware - Phones (Librem 5) - Purism community.
(3) Librem 5 Phone – Birch - Purism. Librem 5 Phone – Birch.
(4) undefined. Librem 5 Phone – Evergreen.

I don’t think Librem 5 phone is relevant here.

[Insurgo]

The only truth is looking inside of the firmwares that are built and their blobs dependencies.

Sorry for references on librem5, and librem15 missing, but they also come in different chipsets depending on their revisions, but it doesn’t change the fact: they are post broadwell and therefore are in ME >= 11, which is not fully neuteurable. I wrote about this so many times in the past, I can’t believe there is still confusion about this but because terminology intricacies.

As described under Platform blobs, collaborators/maintainers/testers for faster problems resolution · Issue #692 · linuxboot/heads · GitHub there is no such thing as fully neutereable ME after =>11 and this documentation is the reference How does it work? · corna/me_cleaner Wiki · GitHub.

---

If we take for example what is built from Heads CircleCI.

• Last build of master at time of writing this https://app.circleci.com/pipelines/github/osresearch/heads/679/workflows/8224ced6-b204-4cf0-b55a-0a2891a709e2
• Let’s pick Librem15v3 https://app.circleci.com/pipelines/github/osresearch/heads/679/workflows/8224ced6-b204-4cf0-b55a-0a2891a709e2/jobs/12681
• Let’s download the build rom artifact https://output.circle-artifacts.com/output/job/e362a61d-1bfb-40f7-b1d7-99f01ed85bd6/artifacts/0/build/x86/librem_15v3/heads-librem_15v3-v0.2.0-1809-gbd2a8eb.rom

user@heads-tests-deb12:~/heads$ ~/heads/blobs/xx30/me_cleaner.py heads-librem_15v3-v0.2.0-1809-gbd2a8eb.rom
Full image detected
Found FPT header at 0x1010
Found 2 partition(s)
Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000
Found FTPR manifest at 0x1478
ME/TXE firmware version 11.0.18.1002 (generation 3)
Public key match: Intel ME, firmware versions 11.x.x.x
The HAP bit is SET
Reading partitions list...
 FTPR (0x00001000 - 0x0000a8000, 0x000a7000 total bytes): NOT removed
 MFS  (0x000a8000 - 0x00010c000, 0x00064000 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0x01)...
Reading FTPR modules list...
 FTPR.man     (uncompressed, 0x001478 - 0x00207c): NOT removed, partition manif.
 rbe.met      (uncompressed, 0x00207c - 0x002112): NOT removed, module metadata
 kernel.met   (uncompressed, 0x002112 - 0x0021a0): NOT removed, module metadata
 syslib.met   (uncompressed, 0x0021a0 - 0x002204): NOT removed, module metadata
 bup.met      (uncompressed, 0x002204 - 0x0026a4): NOT removed, module metadata
 pm.met       (uncompressed, 0x0026a4 - 0x002752): NOT removed, module metadata
 syncman.met  (uncompressed, 0x002752 - 0x0027e8): NOT removed, module metadata
 vfs.met      (uncompressed, 0x0027e8 - 0x003148): NOT removed, module metadata
 evtdisp.met  (uncompressed, 0x003148 - 0x0032d6): NOT removed, module metadata
 loadmgr.met  (uncompressed, 0x0032d6 - 0x0033fe): NOT removed, module metadata
 busdrv.met   (uncompressed, 0x0033fe - 0x0037b0): NOT removed, module metadata
 gpio.met     (uncompressed, 0x0037b0 - 0x0038bc): NOT removed, module metadata
 prtc.met     (uncompressed, 0x0038bc - 0x003a6c): NOT removed, module metadata
 policy.met   (uncompressed, 0x003a6c - 0x003c36): NOT removed, module metadata
 crypto.met   (uncompressed, 0x003c36 - 0x003dc0): NOT removed, module metadata
 heci.met     (uncompressed, 0x003dc0 - 0x003f74): NOT removed, module metadata
 storage.met  (uncompressed, 0x003f74 - 0x004258): NOT removed, module metadata
 pmdrv.met    (uncompressed, 0x004258 - 0x00437c): NOT removed, module metadata
 maestro.met  (uncompressed, 0x00437c - 0x004466): NOT removed, module metadata
 fpf.met      (uncompressed, 0x004466 - 0x00455a): NOT removed, module metadata
 hci.met      (uncompressed, 0x00455a - 0x004704): NOT removed, module metadata
 fwupdate.met (uncompressed, 0x004704 - 0x00480c): NOT removed, module metadata
 ptt.met      (uncompressed, 0x00480c - 0x0048fe): NOT removed, module metadata
 touch_fw.met (uncompressed, 0x0048fe - 0x004a40): NOT removed, module metadata
 rbe          (Huffman     , 0x004a40 - 0x0070c0): NOT removed, essential
 kernel       (Huffman     , 0x0070c0 - 0x015dc0): NOT removed, essential
 syslib       (Huffman     , 0x015dc0 - 0x028a00): NOT removed, essential
 bup          (Huffman     , 0x028a00 - 0x051600): NOT removed, essential
 pm           (LZMA/uncomp., 0x051600 - 0x053f80): removed
 syncman      (LZMA/uncomp., 0x053f80 - 0x0544c0): removed
 vfs          (LZMA/uncomp., 0x0544c0 - 0x05c2c0): removed
 evtdisp      (LZMA/uncomp., 0x05c2c0 - 0x05dd40): removed
 loadmgr      (LZMA/uncomp., 0x05dd40 - 0x060b80): removed
 busdrv       (LZMA/uncomp., 0x060b80 - 0x063980): removed
 gpio         (LZMA/uncomp., 0x063980 - 0x064e00): removed
 prtc         (LZMA/uncomp., 0x064e00 - 0x065bc0): removed
 policy       (LZMA/uncomp., 0x065bc0 - 0x06c280): removed
 crypto       (LZMA/uncomp., 0x06c280 - 0x07be00): removed
 heci         (LZMA/uncomp., 0x07be00 - 0x07fec0): removed
 storage      (LZMA/uncomp., 0x07fec0 - 0x084640): removed
 pmdrv        (LZMA/uncomp., 0x084640 - 0x085e40): removed
 maestro      (LZMA/uncomp., 0x085e40 - 0x088d40): removed
 fpf          (LZMA/uncomp., 0x088d40 - 0x08a740): removed
 hci          (LZMA/uncomp., 0x08a740 - 0x08afc0): removed
 fwupdate     (LZMA/uncomp., 0x08afc0 - 0x08f840): removed
 ptt          (LZMA/uncomp., 0x08f840 - 0x0a3980): removed
 touch_fw     (LZMA/uncomp., 0x0a3980 - 0x0a8000): removed
The ME minimum size should be 352256 bytes (0x56000 bytes)
The ME region can be reduced up to:
 00001000:00056fff me
Checking the FTPR RSA signature... VALID
Done! Good luck!

As you can see, a lot of modules have been removed, but take note of the essential modules, which cannot be removed, just like referred documentation by me_cleaner.

So if we go back at statements: “kernel and rbe”, they are still there.

X230:

user@heads-tests-deb12:~/heads/blobs/xx30$ ./download_clean_me.sh 
Usage: ./download_clean_me.sh -m <me_cleaner>(optional)
### Creating temp dir
### Downloading https://download.lenovo.com/pccbbs/mobiles/g1rg24ww.exe...
--2023-10-16 18:03:33--  https://download.lenovo.com/pccbbs/mobiles/g1rg24ww.exe
Resolving download.lenovo.com (download.lenovo.com)... 23.195.77.12
Connecting to download.lenovo.com (download.lenovo.com)|23.195.77.12|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4626016 (4.4M) [application/octet-stream]
Saving to: ‘g1rg24ww.exe’

g1rg24ww.exe                          100%[=======================================================================>]   4.41M  8.39MB/s    in 0.5s    

2023-10-16 18:03:34 (8.39 MB/s) - ‘g1rg24ww.exe’ saved [4626016/4626016]

### Verifying expected hash of g1rg24ww.exe
g1rg24ww.exe: OK
### Extracting g1rg24ww.exe...
Extracting "Intel Management Engine 8.1 Firmware for Windows 7/8/8.1" - setup data version 5.4.2
 - "app/FwDetect.exe"
 - "app/FwUpdate.exe"
 - "app/FWUpdLcl.exe"
 - "app/FWUpdLcl64.exe"
 - "app/Idrvdll.dll"
 - "app/ME8_5M_Production.bin"
 - "app/MEInfoWin.exe"
 - "app/MEUpdate.CMD"
 - "app/Pmxdll.dll"
 - "app/SLA_TOOLS.pdf"
Done.
### Verifying expected hash of app/ME8_5M_Production.bin
app/ME8_5M_Production.bin: OK
###Applying me_cleaner to neuter+deactivate+maximize reduction of ME on , outputting minimized ME under /home/user/heads/blobs/xx30/me.bin... 
ME/TXE image detected
Found FPT header at 0x10
Found 23 partition(s)
Found FTPR header: FTPR partition spans from 0x180000 to 0x24a000
ME/TXE firmware version 8.1.72.3002
Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x
Reading partitions list...
 ???? (0x000003c0 - 0x000000400, 0x00000040 total bytes): removed
 FOVD (0x00000400 - 0x000001000, 0x00000c00 total bytes): removed
 MDES (0x00001000 - 0x000002000, 0x00001000 total bytes): removed
 FCRS (0x00002000 - 0x000003000, 0x00001000 total bytes): removed
 EFFS (0x00003000 - 0x0000df000, 0x000dc000 total bytes): removed
 BIAL (NVRAM partition, no data, 0x0000add0 total bytes): nothing to remove
 BIEL (NVRAM partition, no data, 0x00003000 total bytes): nothing to remove
 BIIS (NVRAM partition, no data, 0x00036000 total bytes): nothing to remove
 NVCL (NVRAM partition, no data, 0x00010511 total bytes): nothing to remove
 NVCM (NVRAM partition, no data, 0x0000493f total bytes): nothing to remove
 NVCP (NVRAM partition, no data, 0x0000a553 total bytes): nothing to remove
 NVJC (NVRAM partition, no data, 0x00004000 total bytes): nothing to remove
 NVKR (NVRAM partition, no data, 0x0001257d total bytes): nothing to remove
 NVOS (NVRAM partition, no data, 0x00034af7 total bytes): nothing to remove
 NVSH (NVRAM partition, no data, 0x00007609 total bytes): nothing to remove
 NVTD (NVRAM partition, no data, 0x00001eac total bytes): nothing to remove
 PLDM (NVRAM partition, no data, 0x0000a000 total bytes): nothing to remove
 GLUT (0x000df000 - 0x0000e3000, 0x00004000 total bytes): removed
 LOCL (0x000e3000 - 0x0000e7000, 0x00004000 total bytes): removed
 WCOD (0x000e7000 - 0x000140000, 0x00059000 total bytes): removed
 MDMV (0x00140000 - 0x000180000, 0x00040000 total bytes): removed
 FTPR (0x00180000 - 0x00024a000, 0x000ca000 total bytes): NOT removed
 NFTP (0x0024a000 - 0x0004a4000, 0x0025a000 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xed)...
Reading FTPR modules list...
 UPDATE           (LZMA   , 0x1cc508 - 0x1cc6c6       ): removed
 ROMP             (Huffman, fragmented data, ~2 KiB   ): NOT removed, essential
 BUP              (Huffman, fragmented data, ~56 KiB  ): NOT removed, essential
 KERNEL           (Huffman, fragmented data, ~135 KiB ): removed
 POLICY           (Huffman, fragmented data, ~91 KiB  ): removed
 HOSTCOMM         (LZMA   , 0x1cc6c6 - 0x1d343f       ): removed
 RSA              (LZMA   , 0x1d343f - 0x1d872a       ): removed
 CLS              (LZMA   , 0x1d872a - 0x1ddec0       ): removed
 TDT              (LZMA   , 0x1ddec0 - 0x1e45be       ): removed
 FTCS             (Huffman, fragmented data, ~18 KiB  ): removed
 ClsPriv          (LZMA   , 0x1e45be - 0x1e499f       ): removed
 SESSMGR          (LZMA   , 0x1e499f - 0x1f32cb       ): removed
Relocating FTPR from 0x180000 - 0x24a000 to 0xd00 - 0xcad00...
 Adjusting FPT entry...
 Adjusting LUT start offset...
 Adjusting Huffman start offset...
 Adjusting chunks offsets...
 Moving data...
The ME minimum size should be 98304 bytes (0x18000 bytes)
Truncating file at 0x18000...
Checking the FTPR RSA signature... VALID
Done! Good luck!
### Verifying expected hash of me.bin
/home/user/heads/blobs/xx30/me.bin: OK
###Cleaning up...
/home/user/heads/blobs/xx30

X220:

user@heads-tests-deb12:~/heads/blobs/xx20$ ./download_parse_me.sh 
### Creating temp dir
### Downloading https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/83rf46ww.exe...
--2023-10-16 18:02:42--  https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/83rf46ww.exe
Resolving download.lenovo.com (download.lenovo.com)... 23.207.56.164
Connecting to download.lenovo.com (download.lenovo.com)|23.207.56.164|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3661480 (3.5M) [application/octet-stream]
Saving to: ‘83rf46ww.exe’

83rf46ww.exe                          100%[=======================================================================>]   3.49M  6.39MB/s    in 0.5s    

2023-10-16 18:02:44 (6.39 MB/s) - ‘83rf46ww.exe’ saved [3661480/3661480]

### Verifying expected hash of 83rf46ww.exe
83rf46ww.exe: OK
### Extracting 83rf46ww.exe...
Extracting "Intel Management Engine 7.1 Firmware for Windows XP/Vista/7/8" - setup data version 5.4.2
 - "app/ME7_5M_UPD_Production.bin"
Done.
### Verifying expected hash of app/ME7_5M_UPD_Production.bin
app/ME7_5M_UPD_Production.bin: OK
###Generating neuter+deactivate+maximize reduction of ME on , outputting minimized ME under /home/user/heads/blobs/xx20/me.bin... 
Starting ME 7.x Update parser.
 UPDATE           (LZMA   , 0x044a5a - 0x044aec       ): removed
 BUP              (Huffman, fragmented data, ~48 KiB  ): NOT removed, essential
 KERNEL           (Huffman, fragmented data, ~122 KiB ): removed
 POLICY           (Huffman, fragmented data, ~86 KiB  ): removed
 HOSTCOMM         (LZMA   , 0x044aec - 0x04a082       ): removed
 RSA              (LZMA   , 0x04a082 - 0x04eb3f       ): removed
 CLS              (LZMA   , 0x04eb3f - 0x053551       ): removed
 TDT              (LZMA   , 0x053551 - 0x0596fc       ): removed
 FTCS             (Huffman, fragmented data, ~15 KiB  ): removed
Relocating  from 0x0 - 0x0 to 0x400 - 0x400...
 Adjusting FPT entry...
 Adjusting LUT start offset...
 Adjusting Huffman start offset...
 Adjusting chunks offsets...
 Moving data...
The ME minimum size should be 84992 bytes (0x14c00 bytes)
Truncating file at 0x14c00...
/home/user/heads/blobs/xx20/me.bin is VALID
### Verifying expected hash of me.bin
/home/user/heads/blobs/xx20/me.bin: OK
###Cleaning up...
/home/user/heads/blobs/xx20

It is true to say that neutering is applied, but corna doc is right after Skylake:

As you can see, things are a bit more complex but the overall concept is the same: one RSA signature over the hash chains of the modules. As before, the hashes are not checked all at once but only when needed, allowing us to remove some modules without problem. Unfortunately it seems that the hashes of the modules rbe, bup, kernel and syslib are checked together, increasing the number of the fundamental modules to four.

• Sandy: BUP
• Ivy: BUP+ROMP (neutered)
• Skylake+: BUP+RBE+KERNEL+SYSLIB. (partly neutered)

More recent:

• No neutering. Only HAP: Deactivated.

Note: This has nothing to do with Purism but chipset and ME versions coming with those. Purism does what can be done to neuter and their articles are pretty clear on what they do and can do with state of current research and the chipsets in use. So are the other vendors that care enough to disable ME. But newer platforms cannot use the term neutering anymore. It should be partly neutered only, where newer platforms simply can’t neuter anymore on ME>=12 where discussion are continuing here Add soft-disable support for Intel ME 12, 14, 15 and 16 by XutaxKamay · Pull Request #384 · corna/me_cleaner · GitHub

Edit: repointing to the discussion on ME differences 3rd gen vs 10th gen - Intel ME - #24 by Insurgo

[Justin]

ubersecure does this discussion clarify things?

I tremendously appreciate Thierry’s table in Discussion on Purism - #35 by Insurgo (though I regret that he had to make it). I understand it to say that the Comet Lake Librem 14 @ubersecure linked to (previously in another thread now, thx @fsflover ) could be ME Deactivated (or “disabled” to use purism terms) but not neutered or removed. If I’ve misunderstood, please!, anyone, correct me.

Is the Purism Librem 14 Comet Lake FSP also well understood and worthy of discussion?

I’m confused, but thankfully I doubt I’d ever seriously consider buying a Purism product.

@Cid7

What happened previously with Purism?

I wish I had the time and motivation to write a response to this. unman’s comments above, basically sum up my opinion:

@unman

Purism was not the first company to sell neutralized and disabled ME.
They built a company on shilling customers and misdirection.
I don’t say they achieved nothing - I explicitly said that they now look
like a reasonable company.

@unman

As I recall Purism got certification for one laptop. Then produced
another laptop with different hardware, but called it by the same
name, and represented it as also certified…
I remember the mailing list being hit by people who had bought a
laptop that was described as Qubes certified, only for Qubes to make it
clear that that laptop was not certified.

@unman

It’s obvious that we aren’t going to agree: you are invested in
Purism, and I have no interest in them. I don’t like their business
practice and it taints their products for me.

[ubersecure]

@fsflover

@ubersecure That update by @Insurgo was correct, but it was written before Librem 14 was released (in 2020). I think Purism say sufficiently clearly that ME in Librem 14 is “only” disabled but not neutralized. What is unclear with it?

Yes, Purism did say that clearly but I was confused about things like ME version. @Insurgo 's posts have cleared all that up.

[Justin]

I don’t know if this is on topic (@fsflover feel free to move this
wherever you want, buried in the Purism thread if you desire, but
preferably not “hidden” in All Around Qubes).

Personally I miss Taiidan’s perspective. He/she might have been
abrasive, like myself, but at least they tried to speak truth.

Almost five years ago on the qubes-users mailing list Taiidan wrote in
HCL - Purism Librem 13 v2

“People need to know the truth about what they would be purchasing, this
issue isn’t and never was the fact that you are selling non-free laptops -
it is that you are claiming they are somehow open source firwmare/libre/me
disabled when they are not and could never be.”

…

“The business model of somehow keeping up open source firmware releases
with new x86 hardware without any vendor cooperation is impossible- it
would take years and millions to reverse engineer FSP thus x86 will
never be free.”

…

"X230 can’t have ME disabled like T400 only nerfed the hw init “bup”
module still runs (although more than skylake stuff where the kernel
runs and then is politely asked to shut off)

My (Justin’s) Commentary:

The HAP bit flip is simply asking Intel to shut off the Management
Engine. If you don’t trust Intel ME, why would you think kindly asking
them to please stop running their propriety, barely documented (and
certainly unsecure) kernel makes any sense?

Reference: (sadly this is “Only visible to members of groups: moderators, off-topic-moderators, trust_level_2, trust_level_3, trust_level_4”)

Nevertheless to repeat myself because it’s only visible to members of groups: moderators, off-topic-moderators, trust_level_2, trust_level_3, trust_level_4:

“To paraphrase a wise (former?) qubes user, Your threat model is not
my threat model, but your threat model is OK.”

ME/PSP, FSP, EC, propriety blobs, etc etc likely undermine Qubes
fantastically secure software. Still software is unlikely to be able to
protect users from firmware, never mind hardware bugs and design flaws.

I believe @Sven 's work on Laptops/desktops that work well with Qubes OS
is extremely laudable and important work. I hope the qubes community
will continue to support this effort while still being honest about
hardware security issues

Just my two cents… Best regards.

P.S. Not everyone can afford hardware expenditures every couple years.
Security IMHO should not only be available to the rich!

[ubersecure]

@Justin

ubersecure does this discussion clarify things?

Yes, indeed.

But my motivation is to determine which system to buy, and I am still not clear on how important neutering is?

The threat model is “nsa + co” remotely compromising my privacy.

I guess no one knows for sure, but I am still trying to determine which option give the most hope.

[Justin]

@ubersecure

The threat model is “nsa + co” remotely compromising my privacy.

That’s a tough one for sure (maybe impossible).

@ubersecure

I guess no one knows for sure,

Certainly no one who can speak freely in public.

@ubersecure

I am still trying to determine which option give the most hope.

I wish you the best on your quest. Please keep the community informed about what you discover. Best…

[Insurgo]

@Insurgo

Edit: repointing to the discussion on ME differences 3rd gen vs 10th gen - Intel ME - #24 by Insurgo

As said in other thread, the problem is vocabulary.
I get confused myself here taking a step back and re-reading what was written before because of lack of consensus on vocabulary to be used so I completely understand others do not get the facts right.

Neutered vs minimized vs partly neutered.
Disabled vs deactivated.

The problem vanishes on recent platforms since neutering is less and less possible, if unfeasible anymore, where HAP bit became the norm in UEFI firmware variants. The points still lies there. And lack of literature stating that HAP is unsafe is the only faith people can have that even if modules are there, they aren’t used. We can only trust that the new signature scheme guarantees that integrity of ME is now somewhat guaranteed since neutering is not an option for many, but yet again, this is a “manufacture” problem (external flashing, risk of bricking) that was once having a lot of people experimenting on it and trying to get rid of it. After HAP bit discovery, we are now in another status quo where HAP bit is considered satisfactory. And to be honest, I haven’t read anything groundbreaking in that area for a really long time. Good or bad?

[Justin]

In your opinion, would I be oversimplifying to say that the HAP bit
method has furthered the blind faith mentality?

P.S. sorry to bother you with all this. Please feel free to ignore my
inquires.

Best regards… and a HUGE thank you for everything you’ve done and
continue to do.

[qubist]

My cousin’s experience with Purism (which I have witnessed first hand):

• Poor and slow communication (and arrogance from Todd himself)
• Mishandling of E2EE (it all ended up decrypted because they quote everything mindlessly and forward to each other unencrypted). They considered a simple “sorry” was enough. Did I say arrogance?
• Not responding to GDPR erasure requests (which is illegal)

To my mind, people with such approach are incapable to provide anything privacy or security related. From what I have read, “their” essential products are developed by people who come to the company and then leave because they don’t like to work for them any more. Considering the similarities (or equalities) of some Purism’s and Nitrokey’s products, I am questioning who did what and who “acquired” from the other.

Regarding the HAP bit, AFAIK, that was not discovered but provided by Intel themselves to Coreboot developers, under an NDA. That’s why this method of disabling IME has become “the new thing” (supposedly working in a more elegant and guaranteed way by the manufacturer Intel, ).

Nitrokey’s NitroPC (mini) uses an older version of Coreboot and the “old way” of disabling ME.

[Justin]

@qubist

Poor and slow communication (and arrogance from Todd himself)

Based on my research this, unfortunately, is not new.
In a message posted to the qubes-users mailing llist 26 Nov 2018 Re: [qubes-users] HCL - Purism Librem 13 v2

Todd weaver started and owns the company so he isn’t mis-informed he is
simply used to making claims he can’t deliver because he has no ethics,
no real technical skills and he still fails to listen to those who do.

For the record, I don’t know Todd, have never owned a Purism product and “don’t have a horse in this race.” Simply wanted to demonstrate @qubist claims are not new.
Nov 2018 and Oct 2023 and the same concerns are being expressed?

Yikes!

[Justin]

@fsflover

the real reason for the misunderstanding in your quotes/links comes from the misleading original me_cleaner’s definition

Here I think we will have to agree to disagree. Corna’s me_cleaner’s definitions are far more accurate (and technically precise) than Purism’s misleading oversimplified marketing material.

Hopefully we can both agree that

@Insurgo

The only truth is looking inside of the firmwares that are built and their blobs dependencies.

and

@Insurgo

there is no such thing as fully neutereable ME after =>11

Sadly

@Insurgo

we are now in another status quo where HAP bit is considered satisfactory

@fsflover II think it is totally naive to assume

@fsflover

NSA and co. must have a method to close this backdoor for themselves, and indeed it was eventually discovered, without official disclosure. The latter makes it actually more trustable in my view, since Intel definitely doesn’t want you to tinker with Intel ME, but they likely had to provide a way to disable to “appropriate” users. So in the end, it’s quite likely (despite unverifiable) that Intel ME is actually deactivated, or disabled by it’s own will. This is exactly how I understand this

@fsflover

I hope I clarified above that the “official”, from the point of view of the ME software itseld, way of disabling the code gives us a good reason to trust that it works, as long as Intel did not expect that users knew about this possibility.

Do you actually know what the High Assurance Program consisted of?
Do you believe it was merely about deactivating the management engine?
Your comments are full of assumptions and presumptions

@fsflover

(despite [being] unverifiable)

Oh well, as stated earlier, I think we will have to agree to disagree, unless of course you can back up your speeculation. I, and I suspect many others, would welcome it.

Best regards…

P.S. What’s your opinion about Librem’s FSP and other blobs?

[Insurgo]

@Justin

P.S. What’s your opinion about Librem’s FSP and other blobs?

ME, FSP and MRC requirements are not related to Purism (but all plarform assemblers choosing Intel for their chipsets and CPU), but necessities based on how Intel progressed on blobs requirements over time and forcing coreboot to include them or depending on them to have a platform that boots and stay powered on.

Here is an attempt of producing such timeline with Bing to rectify facts through a discussion of more then two hours with it (its useful to correct Bing, since chatgpt uses bing and bing uses chatgpt. At this point correcting it is considered upstream to me… One cannot stop progress. )

I have revised my timeline with more validation and accuracy. I have also shortened it down where feasible without losing context. Here is what I found:

• In 2006, Intel introduced the first version of ME, ME 1.0, on the i965 chipset. It was based on an ARC core and ran the ThreadX RTOS. It provided features such as Active Management Technology (AMT) and Trusted Platform Module (TPM).
• In 2008, researchers from Invisible Things Lab published a paper titled “Attacking Intel Trusted Execution Technology” that revealed some of the vulnerabilities and secrets of Intel ME and its associated technologies¹.
• In 2010, Intel released ME 6.0, which was based on an ARCompact core and ran the ThreadX RTOS. It added support for Anti-Theft Technology (AT) and Identity Protection Technology (IPT).
• In 2013, Joanna Rutkowska, the founder of Qubes OS, published a paper titled “Intel x86 considered harmful” that exposed more details and flaws of Intel ME and its firmware². Also in 2013, Intel introduced ME 9.0, which was based on an ARCompact core and ran the ThreadX RTOS. It added support for Boot Guard, a feature that relies on ME to verify the integrity of the boot firmware³. Also in 2013, Intel introduced the Firmware Support Package (FSP) as a way to provide binary blobs for hardware initialization on various platforms⁴. FSP is a library of functions that can be called by the boot firmware to perform memory, CPU, and chipset initialization. Coreboot started to use FSP as a binary component to boot on platforms that required FSP blobs for hardware initialization, such as Bay Trail and Broadwell⁵. This marked the moment when coreboot could not only do native platform initialization without FSP, as FSP became a mandatory component for some platforms.
• In 2014, Trammell Hudson, a security researcher and coreboot developer, presented his work on reverse engineering and disabling parts of Intel ME at the 31st Chaos Communication Congress⁶. He also shared his code and tools on GitHub⁷. He also posted his findings on the coreboot mailing list⁸, where he discussed with other developers about the implications and limitations of his method.
• In 2015, coreboot added support for using FSP as a binary component, which allowed coreboot to integrate FSP blobs into its own image and call them directly. This method improved the boot speed and reduced the complexity of the boot process. The first platform to use this method was Broadwell, a 14 nm Core-based microarchitecture codenamed Broadwell-U⁹.
• In 2016, a tool called me_cleaner was released on GitHub by Nicola Corna, which is a Python script that can modify an Intel ME firmware image to reduce its ability to interact with the system. The tool supports two ways to disable Intel ME: by removing the non-fundamental partitions and modules from the Intel ME firmware, or by setting the HAP (Intel ME >= 11) or the AltMeDisable (Intel ME < 11) bit in the flash descriptor. The latter method was discovered by Positive Technologies and Igor Skochinsky as a way to disable Intel ME after hardware initialization. The tool was also announced on the coreboot mailing list, where it received positive feedback and suggestions for improvement. Also in 2016, coreboot added support for using FSP 2.0, which was a new version of FSP that introduced a more modular and flexible architecture. FSP 2.0 consisted of three components: FSP-S (silicon initialization), FSP-M (memory initialization), and FSP-T (temporary RAM initialization). The first platform to use FSP 2.0 was Apollo Lake, an Atom-based SoC codenamed Goldmont.
• In 2017, researchers from Positive Technologies announced that they had found a way to execute unsigned code on Intel ME through a USB debugging interface. They also published a blog post titled “Disabling Intel ME 11 via undocumented mode” that explained how to use the HAP bit to disable Intel ME on newer platforms. Also in 2017, coreboot added support for using FSP 2.1, which was an updated version of FSP 2.0 that added support for multi-phase silicon initialization and notification API. The first platform to use FSP 2.1 was Kaby Lake, a 14 nm Core-based microarchitecture codenamed Kaby Lake-U.
• In 2020, researchers from System Security Lab at TU Darmstadt published a paper titled “How to Break and Repair Boot Guard” that analyzed the security and implementation of Intel Boot Guard, a feature that relies on Intel ME to verify the integrity of the boot firmware. They also released a tool called BGuardTester that can test the Boot Guard configuration of a system. Also in 2020, coreboot added support for using FSP 3.0, which was a new version of FSP that added support for multi-die packages and unified silicon initialization API. The first platform to use FSP 3.0 was Gemini Lake, an Atom-based SoC codenamed Goldmont Plus.
• In 2021, researchers from Positive Technologies published a paper titled “Intel CSME: A Forgotten Patch and Vulnerabilities in ROM” that disclosed several vulnerabilities in the Intel Converged Security and Management Engine (CSME), which is the successor of Intel ME on newer platforms. They also demonstrated how to exploit one of these vulnerabilities to execute arbitrary code in the very early stages of the boot process. Also in 2021, coreboot added support for using open-source cache as RAM (CAR) code instead of FSP-T blob on some platforms that supported Intel BootGuard. This reduced the dependency on the FSP-T binary blob and improved the security and performance of the boot process. The first platform to use this method was Comet Lake, a 14 nm Core-based microarchitecture codenamed Comet Lake-U.

I hope this timeline helps you understand the FSP and MRC blobs requirements under coreboot for codename platforms and their relation to the ME research and removal.

Source: Conversation with Bing, 10/18/2023
(1) Intel x86 considered harmful - Invisible Things. https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf.
(2) rootkovska/x86_harmful: The “Intel x86 considered harmful” paper - GitHub. GitHub - rootkovska/x86_harmful: The "Intel x86 considered harmful" paper.
(3) Intel x86 considered harmful (new paper) | The Invisible Things. Intel x86 considered harmful (new paper) | The Invisible Things Blog.
(4) Converged Security (CBnT) coreboot support and tooling. Converged Security (CBnT) coreboot support and tooling.
(5) Intel Hardware Shield – Below-the-OS Security. https://www.intel.com/content/dam/www/central-libraries/us/en/documents/below-the-os-security-white-paper.pdf.
(6) How Intel and PC makers prevent you from modifying your … - PCWorld. How Intel and PC makers prevent you from modifying your laptop's firmware | PCWorld.
(7) Building coreboot with Intel FSP | SpringerLink. Building coreboot with Intel FSP | SpringerLink.
(8) Libreboot – Modifying grub.cfg in CBFS. Libreboot – Modifying grub.cfg in CBFS.
(9) coreboot/api.h at master · coreboot/coreboot · GitHub. coreboot/src/drivers/intel/fsp2_0/include/fsp/api.h at master · coreboot/coreboot · GitHub.

To make things even clearer (Bing is still imperfect of course) , I asked to produce an alternative timeline:

I can produce an alternative timeline showing clearly from which point in time it’s impossible to have coreboot without FSP, without MRC blobs and without ME removed, neutered, disabled or deactivated, with those fact corrections. Here is what I found:

• In 2006, Intel introduced the first version of ME, ME 1.0, on the i965 chipset. It was based on an ARC core and ran the ThreadX RTOS. It provided features such as Active Management Technology (AMT) and Trusted Platform Module (TPM). Coreboot could run on this platform without FSP, MRC blobs or ME removal, as ME was not essential for the boot process and coreboot could perform native platform initialization. This platform used the codename Broadwater.
• In 2010, Intel released ME 6.0, which was based on an ARCompact core and ran the ThreadX RTOS. It added support for Anti-Theft Technology (AT) and Identity Protection Technology (IPT). Coreboot could still run on this platform without FSP, MRC blobs or ME removal, as ME was not essential for the boot process and coreboot could perform native platform initialization. This platform used the codename Cougar Point.
• In 2013, Joanna Rutkowska, the founder of Qubes OS, published a paper titled “Intel x86 considered harmful” that exposed more details and flaws of Intel ME and its firmware. Also in 2013, Intel introduced ME 9.0, which was based on an ARCompact core and ran the ThreadX RTOS. It added support for Boot Guard, a feature that relies on ME to verify the integrity of the boot firmware. Coreboot could still run on this platform without FSP or MRC blobs, but it required ME deactivation to bypass Boot Guard verification. Also in 2013, Intel introduced the Firmware Support Package (FSP) as a way to provide binary blobs for hardware initialization on various platforms. FSP is a library of functions that can be called by the boot firmware to perform memory, CPU, and chipset initialization. Coreboot started to use FSP as a binary component to boot on platforms that required FSP blobs for hardware initialization, such as Bay Trail and Broadwell. This marked the moment when coreboot could not only do native platform initialization without FSP, as FSP became a mandatory component for some platforms. These platforms used the codenames Lynx Point and Wellsburg.
• In 2014, Trammell Hudson, a security researcher and coreboot developer, presented his work on reverse engineering and disabling parts of Intel ME at the 31st Chaos Communication Congress. He also shared his code and tools on GitHub. He also posted his findings on the coreboot mailing list, where he discussed with other developers about the implications and limitations of his method.
• In 2015, Intel launched ME 11.0, which was based on an Intel Quark x86-based 32-bit CPU and ran the MINIX 3 operating system. It introduced a new firmware partition table (FPT) and a new firmware file system (EFFS). It also added support for Converged Security and Management Engine (CSME), which is the successor of ME on newer platforms. ME 11.0 also included a Memory Reference Code (MRC) blob, which is a part of the BIOS that determines how the computer’s memory (RAM) will be initialized, and adjusts memory timing algorithms correctly for the effects of any modifications set by the user or computer hardware. Coreboot started to use the MRC blob to initialize the memory controller on platforms that supported ME 11.0 or CSME, such as Skylake and Kaby Lake. This marked the moment when coreboot could not only do native memory initialization without MRC, as MRC became a mandatory component for some platforms. These platforms used the codenames Sunrise Point and Union Point.
• In 2016, a tool called me_cleaner was released on GitHub by Nicola Corna, which is a Python script that can modify an Intel ME firmware image to reduce its ability to interact with the system. The tool supports two ways to disable Intel ME: by removing the non-fundamental partitions and modules from the Intel ME firmware, or by setting the HAP (Intel ME >= 11) or the AltMeDisable (Intel ME < 11) bit in the flash descriptor. The latter method was discovered by Positive Technologies and Igor Skochinsky as a way to disable Intel ME after hardware initialization. The tool was also announced on the coreboot mailing list, where it received positive feedback and suggestions for improvement. Also in 2016, coreboot added support for using FSP 2.0, which was a new version of FSP that introduced a more modular and flexible architecture. FSP 2.0 consisted of three components: FSP-S (silicon initialization), FSP-M (memory initialization), and FSP-T (temporary RAM initialization). The first platform to use FSP 2.0 was Apollo Lake, an Atom-based SoC codenamed Goldmont.
• In 2017, researchers from Positive Technologies announced that they had found a way to execute unsigned code on Intel ME through a USB debugging interface. They also published a blog post titled “Disabling Intel ME 11 via undocumented mode” that explained how to use the HAP bit to disable Intel ME on newer platforms. Also in 2017, coreboot added support for using FSP 2.1, which was an updated version of FSP 2.0 that added support for multi-phase silicon initialization and notification API. The first platform to use FSP 2.1 was Kaby Lake, a 14 nm Core-based microarchitecture codenamed Kaby Lake-U.
• In 2020, researchers from System Security Lab at TU Darmstadt published a paper titled “How to Break and Repair Boot Guard” that analyzed the security and implementation of Intel Boot Guard, a feature that relies on Intel ME to verify the integrity of the boot firmware. They also released a tool called BGuardTester that can test the Boot Guard configuration of a system. Coreboot could still run on this platform without FSP or MRC blobs, but it required ME deactivation to bypass Boot Guard verification. It also required using tools from 9elements and Intel to provision and fuse Boot Guard on platforms that supported it. These platforms used the codenames Lewisburg and Purley.
• In 2021, researchers from Positive Technologies published a paper titled “Intel CSME: A Forgotten Patch and Vulnerabilities in ROM” that disclosed several vulnerabilities in the Intel Converged Security and Management Engine (CSME), which is the successor of Intel ME on newer platforms. They also demonstrated how to exploit one of these vulnerabilities to execute arbitrary code in the very early stages of the boot process. Coreboot could still run on this platform without FSP or MRC blobs, but it required ME deactivation to bypass CSME verification. It also required using tools from 9elements and Intel to provision and fuse CSME on platforms that supported it. These platforms used the codenames Cannon Point and Glacier Falls.

I hope this timeline helps you understand the FSP and MRC blobs requirements under coreboot for codename platforms and their relation to the ME research and removal.

An attempt to produce table with Bing

I can separate FSP into their own names and add any other blobs required by coreboot in link with the produced timeline requirements. Here is what I found:

Microarchitecture	Codename	FSP-S	FSP-M	FSP-T	MRC	ME	UGOP
i965	Broadwater	No	No	No	No	No	No
Cougar Point	Cougar Point	No	No	No	No	No	No
Lynx Point/Wellsburg	Bay Trail/Broadwell	Yes	Yes	Yes (optional) ¹²³⁴⁵	No (optional)	Yes (optional)	Yes (optional)
Sunrise Point/Union Point	Skylake/Kaby Lake/Coffee Lake/Whiskey Lake/Comet Lake/Rocket Lake/Alder Lake/…	Yes (optional)	Yes (optional)	Yes (optional)	Yes (optional)	Yes (optional)	Yes (optional)
Lewisburg/Purley/Cannon Point/Glacier Falls/…	Gemini Lake/Cannon Lake/Ice Lake/Tiger Lake/Sapphire Rapids/…	Yes (optional) [26]	Yes (optional) [27]	Yes (optional) [28]	Yes (optional) [29]	Yes (optional) [30]	Yes (optional) [31]

Haswell is not listed in the table because it does not use FSP, but it does use MRC and ME blobs. Haswell platforms used the codenames Lynx Point and Wellsburg. According to the coreboot wiki, Haswell platforms require a Memory Reference Code blob to initialize the memory controller. The MRC blob is a part of the BIOS that determines how the computer’s memory (RAM) will be initialized, and adjusts memory timing algorithms correctly for the effects of any modifications set by the user or computer hardware. The MRC blob can be extracted from a vendor firmware or from a Google Chrome OS recovery image. Haswell platforms also require an Intel Management Engine blob to enable Boot Guard, a feature that relies on ME to verify the integrity of the boot firmware. The ME blob can be minimized by using me_cleaner, a tool that removes non-fundamental partitions and modules from the ME firmware. However, this also does not completely remove ME from the system, as some code is still needed for hardware initialization.

I hope this table helps you understand the FSP components and blobs requirements for Intel platforms. If you have any other questions, please feel free to ask me.

---

Multiple edits with facts corrections. Hopefully Bing will be able to answer those questions correctly with knowledge fed to her… Again this is imperfect but I think it gets the gist out of it.

If one is to blame here, it would be Intel. Not downstream hardware assemblers needing chipsets or the ones that tries to do the best with what’s already existing, providing and what is actually desired from consumers because availability/demand/price range.

Intel will continue to push blobs in open source firmware. The industry big players will all continue to push blobs.

Watch coreboot mailing list to see recent power relations out there with Intel trying to push for ugop blobs recently. Intel is closing down the ecosystem unless proven otherwise.

AMD promised things, have not delivered yet. Drivers are open source, but now depend on firmware blobs that need to be provided by kernel that are closed source…

Blobs everywhere people in newer hardware. Facts. Guarantee of security is that they don’t change if measured and are as expected(signed).
Their content is unknown unless open source.
That’s how it is unless we choose something else.

[fsflover]

@Insurgo

they are post broadwell and therefore are in ME >= 11, which is not fully neuteurable

What is “fully neuteurable” and who said that it was possible? Again, confusing terminology that was never introduced by Purism – probably for a reason. “Neutralizing” was never supposed to be “full”. In my understanding, Purism never tried to hide it and it was always pretty clear about its non-full nature. “Fully neutred” should be called “removed”. And yes, it’s impossible for ME>=11.

By the way, I already discussed it on this forum last year:

@fsflover

You cannot do much with 360 KB on my Librem 15, especially considering that it must power on the system and perform a few low-level tasks at the same time.

@Insurgo

I can’t believe there is still confusion about this but because terminology intricacies.

I have no idea where you took the above definition. Could you point it out for me? Not only Purism is careful about the definitions here, they explained all the details about their neuterization:

As we’ve seen on Broadwell, that meant almost 93% of the code is removed and only 7% remains (that proportion is different on Skylake, see further below).

The total ME size dropped from 2.5MB to 360KB, which means that 14.42% of the code remains, while 85.58% of the code was neutralized with me_cleaner.

the ME is disabled using the “HAP” method

and provided the code for doing this. Which other company (selling modern hardware) did it? I wish System76 or Framework were discussing this bringing attention to it. Ok, the former do something useful here but much less. Purism is bad but everyone else is worse, following the trend of silence and compliance.

Given the reasons above, I’m convinced that Librem 13v2, v3, v4 as well as Librems 15 should have “Yes” in column “Neutering”. Maybe with a comment “partially” if you will.

@Insurgo

Purism does what can be done to neuter and their articles are pretty clear on what they do and can do with state of current research and the chipsets in use.

So we agree here.

@Insurgo

So are the other vendors that care enough to disable ME.

Of which none ship modern hardware… So for me there is simply no choice. Yes, I care about performance of my machine, especially with bugs like this or this.

@Insurgo

But newer platforms cannot use the term neutering anymore.

Purism clearly explained what they mean and have a full right to use these terms. (Well, had in the past, because for Librem 14 only disablement is possible of course.) I don’t see why one has to invent alternative terms for “ME is (fully) removed”.

@Justin

unman’s comments above, basically sum up my opinion:

@unman

I explicitly said that they now look
like a reasonable company.

I also agree with you on this one.

@unman

It’s obvious that we aren’t going to agree: you are invested in
Purism

I don’t understand this argument at all; isn’t it a personal attack? I do not care and never cared about Purism. I am using their devices, because they explicitly support FSF, and I do care about freedom, and I am invested in free software. Apart from that, Purism make real progress with freedom with modern devices as much as possible,

@unman

Purism was not the first company to sell neutralized and disabled ME.

make a lot of fuss about the problems of Intel ME, educating the public about it; explicitly try to promote the importance of security in computing, officially support and promote Qubes OS. Which other company providing modern hardware is doing this? I am happy to leave Purism and forget about it whenever a better company appears. Sorry @Insurgo I love what you are doing and promise to recommend your company to interested friends, but I need a faster hardware for my tasks.

[FranklyFlawless]

Most of my interest in Purism comes down to two points:

• Hardware kill switches
• Reverse engineering Intel ME

The former gives me the ability to distrust the hardware at whim, while the latter reduces the amount of trust placed on Intel and also reducing the firmware’s attack surface. Ultimately, I want the root of trust to be on me, not someone else, so Purism’s vision of empowering the user coincides with my values. From my current understanding and awareness, no other company shares both of these interests, which is why I currently have a Librem 5 USA and a Librem 14.

Purism also has an anti-interdiction service, but I am well aware of how their security measures can be circumvented at this point, so I do not give much credibility to it. This AnarSec guide briefly explains bypass methods for the screws, although it does not address the security seals:

AnarSec | Make Your Electronics Tamper-Evident

The Librem 14 also has open-source EC firmware, which is nice-to-have.

[skyvine]

@FranklyFlawless

Purism also has an anti-interdiction service, but I am well aware of how their security measures can be circumvented at this point

Could you expand on this? I’m a little hesitant to ask because sharing knowledge about how to successfully perform attacks is dangerous, but as someone who has used this service in the past (and might again in the future) I’d like to be informed about possible problems, if you can speak in general terms.