A while ago, I asked on the UEFI development list for someone to clarify AMD’s UEFI strategy. I’m unfortunately, not that strong on AMD64 technology, and was a bit confused by the available documentation as to a few things. Gary Simpson, Firmware Architect at AMD, was kind enough to reply to my questions, with verbose reponses. I’ve slightly edited the message, cleaning up the email intro and simplifying my questions, but did not alter any text responses from AMD. Below, lines beginning with “Q:” are questions from me to AMD, and the bold lines with “A:” are Gary’s replies.
Q: Can anyone explain AMD’s strategy w/r/t UEFI and BIOS, UEFI and coreboot?
A: Here’s some quick background: AMD is a founding Board member (i.e. Promoter) of the UEFI Forum and an active member in most of the work groups. We are proponents of the UEFI and ACPI interfaces (because they provide standardized firmware API’s, allowing shrink-wrapped OS distributions, without customized drivers, enabling end-user OS flexibility and choice). Also, despite some birthing pains with individual implementations, UEFI is enormously more secure than legacy BIOS was. AMD’s evolution from legacy BIOS to UEFI has happened over the last ten years in sync with the schedules of our industry partners (IBV’s, OEM’s) and their code bases. We’re not seeing any demand for legacy BIOS enablement anymore, so we no longer focus any effort there. Coreboot is the only remaining legacy code base we enable. Coreboot enablement is provided by AMD’s embedded group for a market-appropriate subset of our chips.
By the way, you may be assuming that the traditional competitiveness between companies persists in the UEFI Forum and the spec work groups that it oversees. But there is actually very little of that (especially compared with a lot of other industry-standards bodies). The general attitude within UEFI is that the firmware layer should be unified, interoperable, well-specified and secure. There is no room for competition or company-specific advantage in the firmware layer. (Then, of course, we all go home to our individual companies and work to create competitive advantage at other layers, such as hardware or higher-level software.) I just want to make sure you understand the atmosphere of cooperation and common-cause that exists between the various OEM’s, Silicon Vendors, OS Vendors, IBV’s, and others that make up the UEFI Forum. That cooperative atmosphere pervades the UEFI work groups, as well as the UEFI Board of Directors.
Q: What AMD X64 models use UEFI, what models use BIOS, what models use coreboot?
A: We don’t specify or control this. Our customers can implement whatever platform firmware solution they choose. However, the firmware components AMD provides focus primarily on UEFI solutions. As mentioned, our embedded group also enables coreboot for a selected subset of our chips. Coreboot is the only legacy code base we still target. For coreboot, we maintain wrappers and a centralized function dispatcher, but our core code is natively targeted at the various UEFI-style code bases used by our IBV partners, our OEM customers, and Tianocore (e.g. EDKII).
Q: I’m unclear if current/upcoming AMD X64 models are still using BIOS on most or only some of their systems, as well as coreboot -vs- UEFI usage and future plans.
A: Internally, we create Customer Reference Boards (CRB’s) and build platform firmware in-house to support them. These in-house BIOS’s, which we use to bring-up and validate our new silicon designs, are all UEFI-based. These are almost always based on our AGESA firmware (see below) combined with a platform code base from one of the IBV’s. Additionally, AMD’s embedded team ports coreboot to their versions of the CRB’s.
Q: Are there different goals for UEFI/BIOS/coreboot for consumer desktop/laptop models -vs- server models? I’ve heard one person speculate that servers are focusing on BIOS, laptops are focusing on GPUs/DirectX [and perhaps UEFI].
A: AMD’s goal is simply to provide what our customers want and need. Server manufacturers were, in general, slower to transition from legacy to UEFI, but we are no longer seeing any demand from them for legacy BIOS.
Q: I’m really unclear how they can get Win8 logos if they’re using BIOS. If they’re getting logos for those systems. Do AMD systems have less Win8 technical restrictions than Intel systems in this regard?
A: In combination with the BIOS Vendors and/or the OEM’s, AMD makes UEFI solutions (supporting Secure Boot, etc.) available for all our chips. We qualify for our Win8 and Win10 logo certifications the old fashioned way – by passing the tests. We make sure that all of our CRB’s pass the certifications tests, and we assist our OEM customers as needed to make sure that their production systems pass as well.
Q: What is AMD equivalent of Intel FSP, for closed-source blobs need alongside Tianocore open source?
A: Our deliverable is called AGESA (AMD Generic Encapsulated SW Architecture). It plugs into the IBV and OEM code bases and does initialization and configuration of the AMD silicon (CPU, GPU, FCH (southbridge), GNB (Graphics North Bridge), etc.). We private-license AGESA source (for free) to our IBV and OEM partners. For coreboot, AGESA is currently provided as a binary module. We did previously publish AGESA open-source in the coreboot repository for a few of our chips over the last several years. You can have a look at those if you’re interested.
Q: How do I debug UEFI on AMD systems, like I can use Intel WinDbg/GDB-based solution for debugging Tianocore with Tunnel Mountain box?
A: AMD does not have an equivalent to Tunnel Mountain. There aren’t any motherboard manufacturers willing to produce and sell such a board, since our volumes would be smaller than Tunnel Mountain. We do design and build Customer Reference Boards for each new chip. The CRB volumes are small and the cost is high, so they mostly go to larger customers. Even inside AMD, these are usually in short supply.
Q: Are you going to port LUVos (and LUV-live) — including it’s new and bundled various tests, especially CHIPSEC — to your systems? CHIPSEC won’t work on AMD64 systems, only Intel systems, implementations are different.
A: We don’t have any current plans to do this, but your question may cause us to do more investigation in this area.
Q: For AMD’s new ARM Ltd.-based systems, are they going to use UEFI on all of them, or just some? What will be used on others, U-Boot or something else?
A: This is an area where we are feeling our way forward. Different customers will want different things. We will try to accommodate them all as well as we can. We plan to offer AGESA for UEFI code bases only, so we won’t support U-Boot directly, but we will enable a UEFI solution that creates a Flattened Device Tree, which should boot any OS’s that normally sit on top of U-Boot.
Q: Are you using Linaro for UEFI bits and making your own ARM firmware, our outsourcing to IBV, if so which?
A: We are working with IBV’s, replicating the traditional firmware-development process from the x86 PC world, but we recognize that traditional ARM-embedded customers may be looking for a free-source stack from us, so we are working to prepare for that possibility as well.
Q: Are you going to help Linaro with their AArch64 port of LUV-live and CHIPSEC, especially including AMD-specific AArch64 implementation issues?
A: No plans yet, but we will investigate.
—- [End of ‘interview’.]
Thanks, Gary, for the detailed answers to my many ignorant questions! For more information, see the email thread on the edk2-devel mailing list, mainly see Gary’s response on July 31st:
https://lists.01.org/mailman/listinfo/edk2-devel
It is especially good to hear about AGESA being open source! I hope Intel can match that bar, with FSP…
Since the responses from Gary, I’ve done two AMD64-centric blog posts, one on the most recent (?) vulnerability, and one on ASESA.
Some additional questions I should’ve asked but didn’t think of until now:
Q: Has AMD or any AGESA licensee (IBV, OEM) ever hired an security audit of the AGESA sources, and published the results?
Q: Does the AMD’s SimNow, either Public or Partner release, support OVMF (the public release appears to not), or is there any other emulator/simulator accurate enough to facilitate porting of CHIPSEC to AMD64 systems?
Q: Can you clarify use of TrustZone on AMD64 — not ARM Ltd.-based AArch32/AArch64 systems? Does TrustZone even work on non-ARM systems as-is, or was this a new port? Are there any more technical details you can point us to for this?
Again, thanks Gary! For the sake of enterprise security, I hope AMD helps with and AMD64 port of CHIPSEC, or at least helps document the issues that need to be removed and added to and AMD64 port, so the open source community can help with the port.
Firmware Security 