Users ask firmware vendors for open source option

Vendors, your compiled code is an firmware attack vector, and makes it harder to trust your product. Secure Boot and signed images are not silver bullets. If you made golden images available, as per NIST 147, we could at least tell if your blobs have changed. But trusting blobs is not enough, there’s enough HW/FW vulnerabilities, and opportunities for attackers to subvert the supply chain. Only open source firmware will solve the firmware blob security problem. Intel has FSP, AMD has AGESA. All IBVs ship closed-source products, no open source vendors, and OEMs/IHVs ship closed-source drivers. Giving us an open source option would solve this problem. IBM claims the OpenPOWER is blob-free, but I’ve yet to verify this. RISC-V is also an ISA that also may be blob-free at the firmware level, depending on the manufacturer. Both OpenPOWER and RISC-V may offer some alternatives to current processors, if they wish to keep with status quo. I hope to see more security standards require the option to build firmware from source, and user ability to reinstall from their own locally-compiled version. And at least requiring that vendors ship hashes for all the blobs they ship.


Dear AMD, could you please release the Platform Security Processor (PSP) source code to the Coreboot / Libreboot project? (or publicly)
Thanks for the inquiry. Currently we do not have plans to release source code but you make a good argument for reasons to do so. We will evaluate and find a way to work with security vendors and the community to everyone’s benefit.
–AMD_jamesProduct Manager 487 points 4 hours ago 

https://www.coreboot.org/Binary_situation https://libreboot.org/faq/#amd



Schneier: avoid Intel/AMD hardware, Intel ME, and UEFI

[[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;”







new Intel FSP 2.0 documents available

Vincent Zimmer of Intel UEFI has posted TWO blog posts, to catch up to.

In the first, he point out some newly-released Intel FSP 2.0 documents:



In the second, he talks about UEFI history, focused on the 2 editions of the Beyond BIOS book (and the recent UEFI reference book in comic book pop culture).



PS: Intel Press, the web pages (including errata) for the Beyond BIOS 2nd Edition and UEFI Shell books are broken. It sucks to have an $80 book with a broken web site. Nothing personal, it seems most tech book publishers are terrible at persistant web sites and ‘cool URIs’. 😦


FSP integrating with coreboot and UEFI

Vincent has a new blog post on Intel FSP (Firmware Support Package), discussing the phases of firmware init, and how FSP works with both coreboot and UEFI.





More on Intel FSP

First, Vincent replied to my last FSP post with an URL to another FSP-related spec, the Boot Setting File (BSF) spec, see the comments here:



Second, Vincent has two posts of his own on FSP, I may’ve blogged about one, but I believe the other one is new, there’s a lot of new FSP links to start learning…: