Discussion on Purism

[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.