https://www.phoronix.com/scan.php?page=news_item&px=Intel-Open-Source-FSP-Likely
Please leave a Comment on this post if you have more info, other than above.
Tag: Intel FSP
Purism pulls FSP blog post
Re: https://firmwaresecurity.com/2018/04/03/intel-fsp-reverse-engineering-finding-the-real-entry-point/
https://puri.sm/posts/intel-fsp-reverse-engineering-finding-the-real-entry-point/
2018-04-23 update: after receiving a courtesy request from Intel’s Director of Software Infrastructure, we have decided to remove this post’s technical contents while we investigate our options.
Intel FSP reverse engineering: finding the real entry point!
https://puri.sm/posts/intel-fsp-reverse-engineering-finding-the-real-entry-point/
Reversing? I thought that Purism was an Intel FSP source licensee? Oh well.
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;”
I
See-also:
Intel on Intel FSP 2.0 and coreboot
Giri Mudusuru and Vincent Zimmer of Intel gave a presentation with an overview of Intel FSP 2.0:
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:
https://firmware.intel.com/blog/how-build-it
https://firmware.intel.com/develop
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).
http://vzimmer.blogspot.com/2016/06/shields-and-networks.html
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.
https://firmware.intel.com/blog/building-platform-firmware-solution
Click to access A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf
Intel FSP v2 in 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…:
http://vzimmer.blogspot.com/2016/04/open-source-platforms-fsp-consumers-fsp.html
https://firmware.intel.com/blog/open-source-platforms-edkii-using-intel-fsp
Intel FSP 2.0
Jiewen Yao of Intel submitted a 19-part patch to the UEFI Forum’s EDK2 project today, adding Intel FSP 2.0 support.
(The comments for the patch are also the first time I’ve seen a pointer to the 2.0 FSP spec. Strangely, at the moment Intel.com is down for me, though the rest of the intarwebs appears to be up, so I cannot verify the FSP PDF URL…)
This series of patch is to support FSP2.0 specification at
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf
Some major updates include:
1) One FSP binary is separated to multiple components:
FSP-T, FSP-M, FSP-S, and optional FSP-O.
Each component has its own configuration data region.
2) All FSP-APIs use same UPD format – FSP_UPD_HEADER.
3) Add EnumInitPhaseEndOfFirmware notifyphase.
4) FSP1.1/FSP1.0 compatibility is NOT maintained.
The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch, or move FSP1.1 support to platform directory.
We also add rename Fsp* to FspWrapper* in IntelFspWrapperPkg, to indicate that it is for FspWrapper only.
IntelFspPkg: Update FSP header file to follow FSP2.0 spec.
IntelFspPkg: Update FSP private header file used by FSP2.0 implementation.
IntelFspPkg-FspCommonLib: Update FSP common lib for FSP2.0.
IntelFspPkg/FspPlatformLib: Update FSP platform lib for FSP2.0.
IntelFspPkg/FspSecPlatformLib: Update FSP SecPlatform lib for FSP2.0.
IntelFspPkg/FspSecCore: Update FSP SecCore for FSP2.0.
IntelFspPkg/FspNotifyPhase: Separate FSP NotifyPhase from DxeIpl to new module.
IntelFspPkg: Update DEC/DSC for FSP2.0.
IntelFspPkg/Tool: Update FSP tool for FSP2.0.
IntelFspWrapperPkg/Ppi: Update FspInitDone to FspSiliconInitDone.
IntelFspWrapperPkg/FspWrapperApiLib: Update FspApiLib to FspWrapperApiLib.
IntelFspWrapperPkg/FspWrapperApiTestLib: Add ApiTestLib as hook.
IntelFspWrapperPkg/FspWrapperHobProcessLib: Update FspHobProcessLib to FspWrapperHobProcessLib.
IntelFspWrapperPkg/FspWrapperPlatformLib: Update FspPlatformInfoLib to FspWrapperPlatformLib.
IntelFspWrapperPkg/FspWrapperPlatformSecLib: Align PlatformSecLib defined in UefiCpuPkg.
IntelFspWrapperPkg/FspWrapperSecCore: Remove FspWrapperSecCore.
IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
IntelFspWrapperPkg/FspWrapperNotifyDxe: Update FspNotifyDxe to FspWrapperNotifyDxe.
IntelFspWrapperPkg: Update DEC/DSC for FSP2.0.
For more info, see the full patch sent to the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel
Vincent on Intel FSP and EDK-II interactions
Vincent Zimmer of Intel has a new blog post, on UEFI’s EDK-II and Intel FSP (Firmware Support Package), and how the FSP works with the EDK-II. Good background, with lots of links.
https://firmware.intel.com/blog/open-source-platforms-edkii-using-intel-fsp
For more information on UEFI and FSP, also read the APress book, which Vincent is one of the authors:
Intel FSP 2.0 in the works?
As reported by Phoronix, it appears that Intel is working on the 2.0 release of their Firmware Support Package (FSP), the pre-compiled set of firmware binaries needed by most firmware solutions to work Intel systems.
http://www.phoronix.com/scan.php?page=news_item&px=Intel-FSP-2.0-Coreboot
http://anzwix.com/a/Coreboot/SocintelapollolakeEnableUsingFSP20Driver
https://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=b37fd67e8757e2eaf3ae7dd453e9aaa1518e9439
http://firmware.intel.com/learn/fsp/about-intel-fsp
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
Purism Librem-13 gets 100% funded
According to this tweet, Purism got their Librem13 laptop funded. Congratulations!
Looking at the above ‘thread’, it mentions two other items of Purism news.
It sounds like that after Notebooks, they’re going to target Tablets, then Smartphones.
“First privacy respecting Librem notebooks. Next: Tablets. And then: Smartphone.”
Also, it looks like they’ll have some more news on their firmware efforts, specifically related to their efforts fighting the Intel Management Engine (ME):
“we have big news soon on freeing the ME. All firmware updates will be provided”
The already have semi-regular posts on their blog by their firmware developer, with some more news that I’ve not covered. I’m not sure what the second sentence above means. Other OEMs currently provide firmware updates to ME already. Providing full source updates would be impressive, but I doubt they meant that.
https://www.crowdsupply.com/purism/librem-13
Purism gets a bit of criticism from some people because their marketing department claims that their BIOS is “almost free”, but they’re using a modern Intel system, which has many blobs and out-of-band activities. Other documentation from Purism clarifies that the “BIOS is not yet free”. Use of FSP is not a 100% requirement for modern Intel systems, it isn’t clear what the mainstream BIOS vendors are using it or alternate code. One recent BIOS vendor, I forget their name, they’re based in Sweden, released a BIOS solution for the Intel Minnowboard, which was not based on FSP. I presume, but am not sure, that anyone who does a FSP alternative codebase would still need some NDA for some specifications from Intel.
The Purism web site says:
While the BIOS is not yet free, the Librem will be the first laptop ever manufactured to ship a modern Intel CPU fused to run unsigned BIOS code, allowing for a future where free software can replace the proprietary, digitally signed BIOS binaries. This marks one of the largest hurdles to a BIOS that runs 100% free software and firmware. Recognizing the importance of this critical step toward consumer freedom, Dr. Richard M. Stallman, president of the Free Software Foundation (FSF), states:
“Getting rid of the signature checking is an important step. While it doesn’t give us free code for the firmware, it means that users will really have control of the firmware once we get free code for it.” – Dr. Richard M. Stallman
There are also hardware components, like the HD or SSD, that are flashable, and therefore upgradeable, but that currently run firmware that is not yet freed. We are working to get freed versions of this firmware! Being the first manufacturer to care about privacy, security, and freedom, we are pushing this message upstream.
Bluntly, I’m not I understand or agree with RMS’s above statements, unclear of the context. Offhand, it seems to me that RMS isn’t considering security at all, only personal freedoms. I want both, and I don’t see why I need to chose just one. I want code to be checked, but I want to be able to control what is run. I get a little worried about some privacy enthusiasts, they sometimes only focus on technology choices that give them personal freedom, and completely ignore the use case of an attacker, who doesn’t care if the binaries were backed by open source or not.
[I want a box with a kill switch, like Purism has. And two-factor authentication required to boot firmware, locally or remotely. And a Developer Mode, like Google ChromeBook Pixel has, to override BIOS and let me do what I want. I want a metal enclosure that covers all ports (Thunderbolt, etc.) when closed, and I want a quality lock integrated into system, to deter Evil Maid from accessing ports or developer mode firmware override. I expect a good key won’t be viable, TSA checkpoints will want the ability to Evil Maid people and a good lock may slow them down.]
This quote from Joanna of Invisible Things Lab summarizes my trust of Purism exactly:
“I agree there are redflags in the @Puri_sm marketing lang. There are also positives, such as @ioerror being on board.”
Purism has a tough job trying to remove blobs from firmware, make system flexible enough for users to install new boot-time software, yet prevent attackers from attacking system, while removing protections that Intel has been adding to deter attackers. With some AMD systems, they may have less firmware to worry about blobs, but will have entirely new silicon attacks, and unlike Intel, ARM doesn’t provide any firmware vulnerability assessment tools. I’m unclear about AMD64 firmware and their AGESA, which is somewhat similar to Intel’s FSP; unclear about blob-removable potential by Purism. Also, AMD, like ARM systems, doesn’t have CHIPSEC or similar tools. Overly slick marketing aside, they’re the only OEM that’s trying to solve this problem — arguably the 2nd, after Bunnie, perhaps — which is nice to see.
It’ll be interesting to see what ISA they choose for their tablet and smartphone devices!
Purism BIOS efforts
Purism mentioned in a Tweet that they have 3 developers working on Intel Management Engine:
They have one document, from the summer, talking about how they’re trying to free the BIOS:
https://puri.sm/posts/freeing-the-bios-the-memory-init-stage/
And another more recently-updated status page:
https://puri.sm/road-to-fsf-ryf-endorsement-and-beyond/
Purism offers the first high-end privacy and freedom-respecting laptops by manufacturing the motherboard and sourcing daughter cards, where all chips are designed to run free software. Purism laptops are completely free from the bootloader through the kernel (with no mystery code, binary blobs, or firmware blobs), including the operating system and all software. We have yet to free the Intel FSP binary and ME binary from within the coreboot BIOS to move us toward FSF RYF endorsement. We are working diligently to free the BIOS, but our goal is to go further than that: Purism also intends to free the firmware within HDDs and SSDs.
I’m still unclear how this will result. I’m of two minds on this: I love the idea of having a system I can trust, so am happy to see projects like Novena and Purism. On the other hand, Purism is fighting Intel’s security mechanisms, and I’m a little concerned the result will remove some Intel defensive technology that makes the system more easily attackable.
Their current model has a kill switch, which is a nice feature. [I’d also like a case that closes access to the ports when closed, and has a LOCK, with a good quality lock, that can’t be easily picked. That’d be an issue for TSA checkpoints, though.] I might also consider getting ride of Suspend/Resume, a lot of attacks happen there, and systems are fast enough these days to live without this feature.
I wish other OEMs would compete with Purism, it would be nice to have more options than a handful of ancient refurbished Thinkpads and a handful of remaining Novenas. The current Purism model is nearly done with funding, only a few days left:
Purism laptops and FSP blobs
Purism is getting some slack about it’s firmware:
http://www.phoronix.com/scan.php?page=news_item&px=Purism-Librem-Still-Blobbed
https://www.phoronix.com/scan.php?page=news_item&px=Librem-15-Rev-2-Coreboot
http://www.phoronix.com/scan.php?page=news_item&px=coreboot-dev-purism
http://www.pcworld.com/article/2960524/laptop-computers/why-linux-enthusiasts-are-arguing-over-purisms-sleek-idealistic-librem-laptops.html
http://www.phoronix.com/forums/forum/software/mobile-linux/813274-purism-librem-laptops-remain-blobbed-up-less-than-interesting
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?
Sage Engineering updates Minnow firmware
Sage Engineering maintains a Coreboot-based, SeaBIOS payload-based firmware for the Intel MinnowBoard MAX.
Today, they’ve announced an updated release. This update allows for flashing the boot image without a hardware device.
“The binary SageBIOS boot ROM image, which is flashed on the development board’s SPI Flash device, is based on the Intel Firmware Support Package (Intel FSP) and coreboot open source initialization. The SageBIOS OSP replaces UEFI firmware that comes installed on both versions of MinnowBoard MAX and will support booting a greater variety of operating systems, including FreeBSD and a variety of RTOS, as well as legacy operating systems such as older versions of Microsoft Windows and even DOS. The SageBIOS OSP will support all the operating systems supported by the native UEFI firmware, such as Windows and Linux. In addition, the SageBIOS OSP will boot both 32-bit and 64-bit operating systems with a single boot image.”
The download of the “demo ROM” is free, but email registration is required.
More information:
http://lists.elinux.org/pipermail/elinux-minnowboard/Week-of-Mon-20150518/001523.html
http://www.se-eng.com/minnow/
Book Review: Embedded Firmware Solutions
Embedded Firmware Solutions: Development Best Practices for the Internet of Things
APress Media
ISBN 978-4842-0071-1
February 2015
Jiming Sun, Marc Jones, Stefan Reinauer, Vincent Zimmer
http://www.apress.com/9781484200711
[I recently finished reading this book. Sadly, I didn’t know about it until the other day, after my LinuxFestNorthWest talk on firmware security tools, someone from Sage pointed out that I omitted this from my More Information slides.]
If you care about firmware development — or just understanding current firmware architecture — you should have this book. It is the only current book with information about modern firmware in use today. The authors are all experienced and well-known firmware developers, including members of the Coreboot and UEFI teams, and there is also an impressive list of tech reviewers. There are 4 areas that this book focuses on:
* Intel Firmware Support Package (FSP), and it’s use in Coreboot and UEFI.
* UEFI and it’s dev platform.
* Coreboot and Chrome use of it.
* Intel Quark and UEFI firmware.
Intel Press has a handful of other UEFI books, but they are years old, this book is only a few months old, and has fresher details on UEFI. I don’t know of any other book with this kind of information on Coreboot, or on Intel FSP. There are a variety of books on Intel’s Minnowboard and Quark/Galileo IoT hardware: most of those books talk about how to write user-level apps, this is the only book that talks about updating the firmware of Intel IoT devices.
I’m looking forward to a second edition in a year or so, once tech changes enough.
Firmware Security 