AMD SEV is a hardware feature designed for the secure encryption of virtual machines. SEV aims to protect virtual machine memory not only from other malicious guests and physical attackers, but also from a possibly malicious hypervisor. This relieves cloud and virtual server customers from fully trusting their server providers and the hypervisors they are using. We present the design and implementation of SEVered, an attack from a malicious hypervisor capable of extracting the full contents of main memory in plaintext from SEV-encrypted virtual machines. SEVered neither requires physical access nor colluding virtual machines, but only relies on a remote communication service, such as a web server, running in the targeted virtual machine. We verify the effectiveness of SEVered on a recent AMD SEV-enabled server platform running different services, such as web or SSH servers, in encrypted virtual machines. With these examples, we demonstrate that SEVered reliably and efficiently extracts all memory contents even in scenarios where the targeted virtual machine is under high load.
AMD tech support can lend some a processor to get around a problem, aka a “Boot Kit”. They have recently updated this procedure:
Unable to Boot New Desktop System Configured with AMD 2nd Generation Ryzen™ Desktop Processor, and AMD Socket AM4 Motherboard
Article Number: PA-100
This document provides information on how to resolve a specific boot issue that may be experienced with some 2nd Generation Ryzen Desktop Processors when installed on an AMD Socket AM4 motherboard.[…]
Spectre Mitigation Update
Today, AMD is providing updates regarding our recommended mitigations for Google Project Zero (GPZ) Variant 2 (Spectre) for Microsoft Windows users. These mitigations require a combination of processor microcode updates from our OEM and motherboard partners, as well as running the current and fully up-to-date version of Windows. For Linux users, AMD recommended mitigations for GPZ Variant 2 were made available to our Linux partners and have been released to distribution earlier this year.[…]
“[…]AMD will provide additional updates on both our analysis of these issues and the related mitigation plans in the coming weeks.”
While many feel that CTS Labs did not do a good job at disclosure, AMD has also not been doing a good job at updating the world about it’s vulns. Still no CVE for the PSP vuln from January, which is related to this one. Does AMD only reply-to vulns which have 24 hour limit response threats, and ignore ones that do not? Why haven’t we seen some response like above for the below fulldisclosure vuln?
The pwrtest.efi is an UEFI Shell tool that help developer to confirm RTC wake function from a system(Support on both Intel and AMD platform). Usage:
pwrtest -s3 -t 10 -w 60 ; 系統會在10 sec delay 後進入S3，然後在60 sec 後喚醒(Wake up)
-s3|-s4|-s5 ;選擇系統的Sx State (Intel platform)
-cb ;做coldboot ，我是透過 gRT->ResetSystem() 方式去做的
-ss ; 做Shutdown，我是透過 gRT->ResetSystem() 方式去做的
-sx value ; 支援AMD platform去做Sx State，因為填的SLP_TYP值不同.
value = 3/4/5 for AMD platform(S3/S4/S5)
value = 5/6/7 for Intel Platform (S3/S4/S5)
pwrtest -sx 4 -t 5 -w 30 ; For AMD Platform, Put system to S4 after 5 sec, then wake after 30 sec.
pwrtest -sx 6 -t 5 -w 30 ; For INTEL Platform, Put system to S4 after 5 sec, then wake after 30 sec.
pwrtest -s3 -t 5 -w 30 ; For INTEL Platform, Put system to S3 after 5 sec, then wake after 30 sec.
pwrtest -r ; Warm boot
pwrtest -cb ; Cold boot
See URL to password-protected live.com-hosted zip containing freeware binary (not open source) in blog post.
The microarchitecture of Intel, AMD and VIA CPUs
An optimization guide for assembly programmers and compiler makers
By Agner Fog. Technical University of Denmark.
Copyright © 1996 – 2017. Last updated 2017-05-02.
White Paper: SOFTWARE TECHNIQUES FOR MANAGING SPECULATION ON AMD PROCESSORS
Speculative execution is a basic principle of all modern processor designs and is critical to support high performance hardware. Recently, researchers have discussed techniques to exploit the speculative behavior of x86 processors and other processors to leak information to unauthorized code * . This paper describes software options to manage speculative execution on AMD processors ** to mitigate the risk of information leakage. Some of these options require a microcode patch that exposes new features to software. The software exploits have recently developed a language around them to make them easier to reference so it is good to review them before we start discussing the architecture and mitigation techniques.
No CVE(s) from US-CERT/NIST/MITRE/NVD.
No AMD tracking id or public response from AMD.
No response from AMD support on the below question on their support forums.
AFAICT, AMD does not have a security advisories page, just occasional announcements on the main PR site. Intel does. Then again, AFAICT, neither does ARM.
Researcher clarifies original statement a bit:
“I would like to clarify that here “remote” means remote code execution on
the TPM component. To mount the attack, local host access is still required.
Sorry if it caused any confusion.”
[Someone just asked me a microcode question, I was digging up some pointers to a microcode tool for someone, ended up cleaning out my browser’s microcode-related bookmarks, and thought I mine as well post a blog entry of the links…]
Revision Date: December 2017
Here’s the complete changelog for this update:
Modified Sections 7.10.1 and 7.10.4.
Modified Sections 15.34.1, 15.34.7.
Added new Section 15.34.10.
Modified Section 15.35.10.
Modified Appendix A, Table A-7.
Not too useful, I wish I could diff PDFs better. I wish the writers would spend a few moments more on the changelog. Here’s the titles of the above sections:
7.10.1 Determining Support for Secure Memory Encryption
7.10.4 Page Table Support
15.34.1 Determining Support for SEV
15.34.10 SEV_STATUS MSR
15.35.10 Control Register Write Traps
Table A-7: Secure Virtual Machine MSRs
Busy year for processor security so far…
AMD-PSP: fTPM Remote Code Execution via crafted EK certificate
From: Cfir Cohen via Fulldisclosure <fulldisclosure () seclists org>
Date: Wed, 3 Jan 2018 09:40:40 -0800
AMD PSP is a dedicated security processor built onto the main CPU die. ARM TrustZone provides an isolated execution environment for sensitive and privileged tasks, such as main x86 core startup. [..] The fTPM trustlet code was found in Coreboot’s git repository  and in several BIOS update files. […] This research focused on vendor specific code that diverged from the TCG spec. […] As far as we know, general exploit mitigation technologies (stack cookies, NX stack, ASLR) are not implemented in the PSP environment. […] Credits: This vulnerability was discovered and reported to AMD by Cfir Cohen of the Google Cloud Security Team.
09-28-17 – Vulnerability reported to AMD Security Team.
12-07-17 – Fix is ready. Vendor works on a rollout to affected partners.
01-03-18 – Public disclosure due to 90 day disclosure deadline.
Phoronix is reporting that Reddit claims that AMD has enabled an option to disable the PSP (Platform Security Processor, the AMD equivalent to Intel’s ME). Interesting if that is the case, please leave a Comment if you have more info on this.
Patroklos (argp) Argyroudis has a new document on microcode reversing:
“Paper notes: Reverse engineering x86 processor microcode
14 Sep 2017”
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