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.