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




One thought on “Schneier: avoid Intel/AMD hardware, Intel ME, and UEFI

  1. “- 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;”

    Sorry to butt in but that quote is from a reply on that blog. Not that it would matter that much though; the quote is only half right here. The part that’s correct is that Intel’s ME and AMD’s AGESA and PSP do pose an incredible security risk. If any blackhat cracking organization, and I include any secret spying agency in that definition as well as they do crack into and compromise systems without any prior consent, manages to find an exploit then all bets are off. The incorrect part is the issue, yet again, being inherently tied to the firmware image architecture. As I explained several times before, the firmware type is irrelevant; it’s the source model that determines whether a CPU with a management engine can be deemed securable thus potentially safe. If both the CPU management engine and the system firmware come with access to an OSI approved source codebase then the base platform can be deemed secure. Since open source implementations of the 4 most widely deployed firmware architectures do exist (PC//AT BIOS has SeaBIOS, UEFI has TianoCORE, Open Firmware has several FOSS implementations including the aforementioned version, and last but not least CoreBoot and its spinoffs LibreBoot and LibreCore), this ball lies squarely in the field in the CPU and Chipset manufacturers. They should provide the necessary glue code. Even the highly frowned upon Secure Boot and TPM aspects of UEFI don’t impose a threat in that, since both are not required for a spec compliant UEFI firmware image.

    I can see this happen in the x86_64 landscape with the traditional Xeon and Opteron CPUs, as they lack an IGPU and thus aren’t tied to all the “”big”” Content and MGEP-LA shenanigans as mandatory HDCP, PAVP, the corresponding master key, the required encryption of the resulting binary, so the Desktop CPUs with an IGPU are out of luck.

    Did Intel give any reaction to the petition regarding blob-free CPUs that the FSF issued some time ago?


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s