Uncategorized

AGESA update info from AMD

[…]Beginning this month, as we promised to you, we began beta testing a new AGESA (v1.0.0.6) that is largely focused on aiding the stability of overclocked DRAM (>DDR4-2667). We are now at the point where that testing can begin transitioning into release candidate and/or production BIOSes for you to download. Depending on the QA/testing practices of your motherboard vendor, full BIOSes based on this code could be available for your motherboard starting in mid to late June. Some customers may already be in luck, however, as there are motherboards—like my Gigabyte GA-AX370-Gaming5 and ASUS Crosshair VI—that already have public betas.
[…]
If you’re the kind of user that just needs (or loves!) virtualization every day, then AGESA 1.0.0.6-based firmware will be a blessing for you thanks to fresh support for PCI Express Access Control Services (ACS). ACS primarily enables support for manual assignment of PCIe graphics cards within logical containers called “IOMMU groups.” The hardware resources of an IOMMU group can then be dedicated to a virtual machine. This capability is especially useful for users that want 3D-accelerated graphics inside a virtual machine. With ACS support, it is possible to split a 2-GPU system such that a host Linux® OS and a Windows VM both have a dedicated graphics cards. The virtual machine can access all the capabilities of the dedicated GPU, and run games inside the virtual machine at near-native performance.[…]

https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram

http://www.tomshardware.com/news/amd-agesa-firmware-update-motherboard,34525.html

 

Standard
Uncategorized

AMD on AGESA updates for Ryzen

AMD has a blog post on the Ryzen, and it talks about AGESA updates!

[…]Let’s talk BIOS updates:
Finally, we wanted to share with you our most recent work on the AMD Generic Encapsulated Software Architecture for AMD Ryzen™ processors. We call it the AGESA™ for short. As a brief primer, the AGESA is responsible for initializing AMD x86-64 processors during boot time, acting as something of a “nucleus” for the BIOS updates you receive for your motherboard. Motherboard vendors take the baseline capabilities of our AGESA releases and build on that infrastructure to create the files you download and flash. We will soon be distributing AGESA point release 1.0.0.4 to our motherboard partners. We expect BIOSes based on this AGESA to start hitting the public in early April, though specific dates will depend on the schedules and QA practices of your motherboard vendor. BIOSes based on this new code will have four important improvements for you:
* We have reduced DRAM latency by approximately 6ns. This can result in higher performance for latency-sensitive applications.
* We resolved a condition where an unusual FMA3 code sequence could cause a system hang.
* We resolved the “overclock sleep bug” where an incorrect CPU frequency could be reported after resuming from S3 sleep.
* AMD Ryzen™ Master no longer requires the High-Precision Event Timer (HPET).

We will continue to update you on future AGESA releases when they’re complete, and we’re already working hard to bring you a May release that focuses on overclocked DDR4 memory.[…]

https://community.amd.com/community/gaming/blog/2017/03/30/amd-ryzen-community-update-2

 

Standard
Uncategorized

AMD updated AGESA?

There are news reports that AMD AGESA has been updated. AMD has a developer section on their web site, but I wish they included a section with news on AGESA, like Intel FSP site does.

https://www.dvhardware.net/article66244.html
https://www.bit-tech.net/news/hardware/2017/03/21/amd-ryzen-fma3-fix-promise/1
https://www.overclock3d.net/news/cpu_mainboard/amd_has_reportedly_released_new_agesa_microcode_for_ryzen/1
https://www.hardocp.com/news/2017/03/20/new_amd_agesa_microcode_in_wild_uefi

https://en.wikipedia.org/wiki/AGESA

Standard
Uncategorized

Nikolaj on AMD AGESA/PSP

Nikolaj Schlej made a comment on the recent Snowden/AMD thread. The comment is on Twitter, so it is in multiple messages. I hope that AMD proves him wrong, AMD can change course, so can Intel, if they choose.

Standard
Uncategorized

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

 

Standard
Uncategorized

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

https://www.schneier.com/blog/archives/2017/01/new_rules_on_da.html

 

See-also:

https://firmwaresecurity.com/2015/12/23/itls-stateless-laptop-proposal/

Standard
Uncategorized

AMD clarifies firmware strategy

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.
http://www.firmwaresecurity.com/2015/08/02/recapping-mareks-jan2015-amd-security-vulnerability/
http://www.firmwaresecurity.com/2015/08/02/amd-agesa/

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.

Standard