AMI has a few press releases about AMD Rhyzen support:
AGESA is the set of binaries used by most AMD systems. Similar, in concept, to Intel’s FSP.
3mdeb points out that the AGESA docs seem to indicate that unbalanced allocation/free of some AGESA resources could have a negative system impact:
The creation and removal of the structure storage depends upon the host environment calling procedure using the AmdCreateStruct and AmdReleaseStruct procedures. Failure to release a structure can cause undesired outcomes.
AGESA – AMD Support & Drivers
Software Optimization Guide for AMD Family 17h Processors
Publication No. 55723 3.00
Revision Date June 2017
SimpleSvm is a minimalistic educational hypervisor for Windows on AMD processors. It aims to provide small and explanational code to use Secure Virtual Machine (SVM), the AMD version of Intel VT-x, with Nested Page Tables (NPT) from a windows driver. SimpleSvm is inspired by SimpleVisor, an Intel x64/EM64T VT-x specific hypervisor for Windows, written by Alex Ionescu.
[…]Beginning this month, as we promised to you, we began beta testing a new AGESA (v220.127.116.11) 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 18.104.22.168-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.[…]
“Microparse: Microcode update parser for AMD, Intel, and VIA processors written in Python 3.x.”
Security Analysis of x86 Processor Microcode
Daming D. Chen, Gail-Joon Ahn
December 11, 2014
Modern computer processors contain an embedded firmware known as microcode that controls decode and execution of x86 instructions. Despite being proprietary and relatively obscure, this microcode can be updated using binaries released by hardware manufacturers to correct processor logic faws (errata). In this paper, we show that a malicious microcode update can potentially implement a new malicious instructions or alter the functionality of existing instructions, including processor-accelerated virtualization or cryptographic primitives. Not only is this attack vector capable of subverting all software-enforced security policies and access controls, but it also leaves behind no postmortem forensic evidence due to the volatile nature of write-only patch memory embedded within the processor. Although supervisor privileges (ring zero) are required to update processor microcode, this attack cannot be easily mitigated due to the implementation of microcode update functionality within processor silicon. Additionally, we reveal the microarchitecture and mechanism of microcode updates, present a security analysis of this attack vector, and provide some mitigation suggestions. A tool for parsing microcode updates has been made open source, in conjunction with a listing of our dataset.
MTS Software Development Engineer – Firmware – Security
The Software Security Engineering group is responsible for enabling Platform Security and Content Protection features. The team develops components across the entire software stack including device drivers, firmware, and application level interfaces, enabling customers to build novel solutions while supporting industry standards. […] Design and implement embedded firmware supporting Platform Security features across a wide range of AMD product lines.[…]
Michael Larabel has an article on Phoronix about an AMD-based Chromebook.
After years of many Intel and ARM Chromebooks, the first AMD-powered Chromebook appears to be gearing up for release.[…]
It looks like most vendors don’t have their boot menus updated to support the new ECC memory they now support…
[…]Once you have an ECC-enabled memory controller, a motherboard with the right traces, and a few sticks of ECC memory, the next step is whether the BIOS/UEFI properly supports ECC. This is where things start getting a little bit iffy. AMD placed all the responsibility for ECC support on the motherboard manufacturers, and they aren’t really willing to step up to the plate and assume that responsibility…you will find out why in the conclusion. As a result, while most motherboard manufacturers have now come to acknowledge that their motherboards are indeed ECC enabled, that is the extent of their involvement. Not one is offering an enable/disable option in the UEFI, and we haven’t seen anyone but ASRock and ASUS have any ECC settings available at the moment.
This lack of settings severely hampers the overall ECC functionality, since a big part of it is that the motherboard should be able to log errors. Right now, no such logging capability exists. Thankfully, there is a possible software solution. The operating system – if it fully supports this new AM4 platform – should have the ability to log errors and corrections. If it does not, the hardware might be silently correcting single-bit errors and even detecting ‘catastrophic’ two-bit errors, but you will never know about it since there will be no log. That’s what we are going to look into next.
To conclude this page, we strongly suspect that just about every AM4 motherboard likely has ECC enabled, or at the very least will in the future. Most motherboard manufacturers certainly aren’t actively supporting it, or even unlocking any of the features that accompany it, but they don’t appear to be maliciously disabling it either. At this point in time, they simply have other way more important things on their plate, like improving memory support, overclocking, ensuring that IOMMU is functional, etc. Furthermore, we strongly suspect that they are presently unable to unlock all of the necessary settings without a newer CPU microcode from AMD.
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 22.214.171.124 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.[…]
Last week, AMD updated “AMD64 Architecture Programmer’s Manual Volume 2: System Programming”. The changelog does not give a lot of information, you have to visit all the Tables/Sections to see what was changed:
Modified CR4 Register, Section 3.1.3.
Removed UD2 in Table 6-1.
Added new bullet in Section 7.1.1.
Modified Note in Table 7-1.
Added new Section 7.4.1.
Clarified Self Modifying Code in Section 7.6.1.
Added UD0 and UD1 instructions in Section 8.2.7.
Added Instructions Retired Performance counter in Section 13.1.1.
Modified Table in Section 15.34.9.
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.
AMD has submitted a similar patch to the Linux kernel, now there is support for AMD SEV in UEFI.
[RFC PATCH v1 0/5] x86: Secure Encrypted Virtualization (AMD)
This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. The SEV feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. The memory controller contains a high performance encryption engine which can be programmed with multiple keys for use by a different VMs in the system. The programming and management of these keys is handled by the AMD Secure Processor firmware which exposes a commands for these tasks. SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the guest must be performed on shared pages (C-bit clear). Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1. KVM SEV RFC  extends the KVM_FEATURE cpuid instruction to indicate whether SEV is enabled. When SEV is enabled then OVMF can use cpuid Fn8000_001F[BX] to get the C-bit position in PTE.
AMD Memory Encryption whitepaper:
AMD64 Architecture Programmer’s Manual (SME is section 7.10, SEV is section 15.34):
Secure Encrypted Virutualization Key Management:
KVM Forum Presentation:
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.
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
[[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;”
A message from Donald Robertson of the Free Software Foundation, quoted verbatim:
‘Large, complex systems such as Talos require minimum order quantities to be met for the component parts in use, in addition to R&D expenditure for prototyping, validation, and conformance testing. We have set the goal at the minimum level required to ensure that we can not only design the Talos systems, but also purchase the parts needed to manufacture these complex machines.’
They need every dollar they can get to make this system a reality. It is a difficult goal, but also one that is critical for the future of free computing. As they note in their explanation of the problem:
‘As of this writing, all currently manufactured, low- to mid-range and higher x86 devices, with the exception of two obsolete AMD CPUs, incorporate a security processor that is cryptographically signed, updateable, unauditable, and for which no source code or documentation has been made public. Worse, these security processors must load and continually execute this signed firmware for the system to either be brought online (AMD) or for it to remain operational (Intel).’
If we want a future in which we can continue to have fully free systems that run only free software, we have to build that future ourselves. The Talos Secure Workstation is a proposed system to help secure that future. Their plans are to create a device that will meet the criteria for [Respects Your Freedom] certification, but in order for their plans to come to fruition, they need your help. You can support their work by backing the project via their [crowdfunding page], or even better, by purchasing a mainboard andaccessory package. Every little bit counts. Will you help support the future of free computing?
Brijesh Singh of AMD submitted a 28-part patch to the Linux-(kernel,efi,kvm,…) mailing lists, with a patch for the the Linux kernel to support AMD’s Secure Encrypted Virtualization (SEV), which relies on the recent AMD Secure Memory Encryption (SME) patch by Tom Lendacky of AMD. I’m excerpting the intro text from part 1/28:
[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)
This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFC.
SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner. While the tag protects VM data inside the SOC, AES with 128 bit encryption protects data outside the SOC. When data leaves or enters the SOC, it is encrypted/decrypted respectively by hardware with a key based on the associated tag.
SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the guest must be performed on shared pages (C-bit clear). Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1.
SEV is designed to protect guest VMs from a benign but vulnerable (i.e. not fully malicious) hypervisor. In particular, it reduces the attack surface of guest VMs and can prevent certain types of VM-escape bugs (e.g. hypervisor read-anywhere) from being used to steal guest data.
The RFC series also includes a crypto driver (psp.ko) which communicates with SEV firmware that runs within the AMD secure processor provides a secure key management interfaces. The hypervisor uses this interface to enable SEV for secure guest and perform common hypervisor activities such as launching, running, snapshotting , migrating and debugging a guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable Qemu to send commands to the SEV firmware during guest life cycle.
The RFC series also includes patches required in guest OS to enable SEV feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid instruction.
The following links provide additional details:
AMD Memory Encryption whitepaper:
AMD64 Architecture Programmer’s Manual:
SME is section 7.10
SEV is section 15.34
Secure Encrypted Virutualization Key Management:
See the full patch for more information.
A follow-up to:
Tom Lendacky of AMD posted v2 of a 20-part patch to most of the linux-kernel (and other) lists, adding support for AMD Secure Memory Encryption (SME), adding more documentation about AMD SME.
Secure Memory Encryption (SME) is a feature found on AMD processors.
SME provides the ability to mark individual pages of memory as encrypted using the standard x86 page tables. A page that is marked encrpyted will be automatically decrypted when read from DRAM and encrypted when written to DRAM. SME can therefore be used to protect the contents of DRAM from physical attacks on the system.
BOOT data (such as EFI related data) is not encyrpted when the system is booted and needs to be accessed as non-encrypted. Add support to the early_memremap API to identify the type of data being accessed so that the proper encryption attribute can be applied. Currently, two types of data are defined, KERNEL_DATA and BOOT_DATA.
Also check out the older v1 patch posting on the lists, there was some interesting technical discussion. The above previous blog post has a pointer to that discussion, as well as some other AMD specs.