Please leave a Comment on this post if you have more info, other than above.
[[UPDATE: See comment from one reader, I mistakingly took below quote to be from Bruce, where it is apparently from someone else. Oops.]]
Bruce Schneier has a new blog post on citizen cybersecurity, including advice for non-US citizens to avoid blobs in firmware.
I hope Intel and AMD are reading this. Are the patents in the IP you’re protecting in your FSP and AGESA binaries really worth the security risks you’re enabling for attackers to all of your systems? Open-sourcing your blobs will reduce this attack vector and make your products more trustworthy, and reduce the potential market loss to RISC-V and OpenPOWER, which by contrast to Intel/AMD have blob-free firmware potential. In addition to criminal use by cybercriminals, backdoors can be “legally” misused by tyrants, bigly. Hidden backdoor management processes like Intel ME should be owner-controllable, including the ability to remove/disable it. How can I use NIST 147 guidance to check the hashes of the hundreds of blobs within the FSP/AGESA packages? The are numerous supply-chain opportunities for firmware attackers to subvert these blobs, at the IHV, OEM, ODM, IBV, some of which also have source access to these packages and modify them (for example Purism modifies FSP for their laptops, but they can’t publish their code, due to Intel NDA).
New Rules on Data Privacy for Non-US Citizens”
“- build firewalls everywhere, if possible based on non-Intel, non-AMD too, hardware platforms or at least supporting old, non-Intel ME and non-UEFI, firmware;”
Purism is getting some slack about it’s firmware:
The first one had a stock UEFI BIOS, the second one will apparently have a coreboot BIOS with a Purism-customized FSP.
It’s not too hard to fork a new Debian OS (PureOS), there’re many to emulate. But being a micro-sized OEM means you have to deal with COTS hardware, which have blobs.
You can’t build a modern computer w/o using it’s hardware. The firmware enables this. Open source projects like Tianocore or coreboot don’t have all the necessary firmware to enable this hardware. On Intel systems, they need the Intel Firmware Support Package (FSP), all the “blobs” needed to enable the hardware. OEMs and IBVs take Intel’s FSP blobs and combine them with the tianocore UEFI code or the coreboot code, and build a firmware image for their system. Some IBVs create their own firmware from spec, w/o FSP, but that is going to take a lot of work, and the NDA’ed material probably means no open source version.
Purism apparently is a licensee of the Intel FSP source code, so they can edit the FSP source and recompile them. I presume this means Purism is under NDA with Intel, and can’t give some details of what they’re doing.
There will always be blobs in current Intel systems. Purism may reduce the number of FSP blobs, but can’t eliminate them. Perhaps Purism should focus on AMD systems, if ASEGA(sp) is open source? Perhaps Purism should focus on ARM systems, where — if sufficiently funded, they could build a chip with just the parts they want; still there are ARM Ltd NDAs. I don’t think Purism — or any similar Linux OEM — will be able to create anything useful until RISV-V is an alternative to the mainstream chips, in a few years. 😦
I hope Purism checks CHIPSEC results before they ship their product. 🙂
I wish Intel would open source FSP. I presume that can’t be done due to NDA issues. I wonder if the open source community would sponsor an FSP alternative, if they could accomplish it w/o the NDA’ed data?