One of the key elements of building a processor is that designing a secure product involves reducing the ‘attack surface’ as much as possible: the fewer ways an attack can get in, the safer your product is. For the white knights of the security world, when a vulnerability is found, the process usually goes through a period of responsible disclosure, i.e. the issue is presented to the company, and they are often given a certain time to fix the issue (to help customers) before the full disclosure is made public (in case it might be swept under the rug). Using this method, a researcher at Google found a vulnerability in the way AMD’s EPYC processors provide Secure Encrypted Virtualization (SEV) which would allow an attacker to recover a secure key that would provide access between previously isolated VMs on a system. AMD has since released an update to the firmware which patches this issue.

AMD’s Secure Encrypted Virtualization (SEV) feature on its EPYC processors allows a system that runs multiple virtual machines through a hypervisor to have those virtual machines purely isolated from one another. By producing encryption keys at the hardware level, the hypervisor can maintain the equivalent of separate secure enclaves between VMs with individual keys. The SEV code runs deep within the EPYC processor, specifically on a Platform Security Processor (PSP), which is a hardened ARM Cortex core.

The SEV feature relies on elliptic-curve cryptography for its secure key generation, which runs when a VM is launched. The VM initiates the elliptic-curve algorithm by providing points along its NIST (National Institute of Standards and Technology) curve and relaying the data based on the private key of the machine. Due to the algorithm involved, if the points provided to the algorithm at the VM launch are both non-standard and small, parts of the algorithm are reduced to zero, leaving behind a path by which over repeated VM launches, an attacker could gather enough data to reassemble the private key of the system. More details are provided in the full disclosure documentation, which indicates that SEV firmware version 0.17 build 11 and earlier are vulnerable.

AMD has identified the code responsible, and has adjusted the algorithm to only accept standard NIST curve points. Any user submitting non-standard points will be met with an error. This fix is applied in SEV firmware version 0.17 build 22, which AMD rolled out to its OEM partners for firmware updates on June 4th. Users that implement SEV within their critical systems are suggested to reach out to their platform vendors for corresponding updates. AMD does state that certificates already generated on vulnerable VMs will still be valid even after VM migration, and as a result VMs should be restarted where possible.

This vulnerability was found by Cfir Cohen as part of the Google Cloud security team, and carries the CVE-2019-9836 designation. AMD’s response to this issue can be found on its security website.

For those interested, the full disclosure document gives the following timeline for this issue:

  • Feb 19th: Vulnerability disclosed to AMD PSIRT
  • Feb 23rd: AMD confirms the bug
  • Feb 25th: Google shares Proof of Concept with AMD
  • May 13th: AMD requests a 30 day extension before full disclosure
  • June 4th: AMD releases fixed firmware to 0.17 Build 22 (AMD)
  • June 7th: AMD requests a 2 week extension
  • June 25th: Public disclosure

Update: It's worth noting that the Elliptic Curve Cryptography was one of the units that the Hygon joint venture changed on its EPYC-like Dhyana processors.

Related Reading

Comments Locked

33 Comments

View All Comments

  • Irata - Wednesday, June 26, 2019 - link

    Good to see Anandtech starting to report on CPU vulnerabilities again
  • shabby - Wednesday, June 26, 2019 - link

    Wonder why they missed a few of the intel ones 🤔
  • azfacea - Wednesday, June 26, 2019 - link

    yea after all its not like the fix for those required losing 40% perf. oh wait
  • imaskar - Wednesday, June 26, 2019 - link

    But this is an article about a fix. There is no full fix for Intel other than disabling SMT completely, right?
  • rocky12345 - Wednesday, June 26, 2019 - link

    Yep when I heard about that exploit and one of the fixes to help make things a bit safer was to disable Intel's Hyper Threading. I was like oh hell no I'm not turning my i7 into a i5 just so I can feel secure. You know what I did not do it and I can still sleep at night and I am still able to fully use my CPU because I am not willing to let fear rule my life. Besides that after being in this industry for over 22 years I am pretty sure I am able to tell when the system is not behaving as it should & have the smarts to correct it without losing 40% of my performance just in case something might happen which has about the same odds as wining one of those big lotteries.
  • rocky12345 - Wednesday, June 26, 2019 - link

    On a side note because there is no edit function that I could find. These exploits that seem to have Intel CPU's the worst is one of the few reasons I am going away from Intel for my next platform upgrade here in the fall of 2019. Heck I have to stay on Windows 10 1709 because it is one of the ones you can still control whether you have to infest your system with performance losing updates to maybe fix all of the exploits that affect Intel CPU's. I am on a Sandy Bridge i7 still and form the numbers I have seen so far these CPU's and Haswell lose up to 35%-40% performance in a lot of tasks by doing the patches which is not an option I am willing to take. I can not wait to get my AMD platform upgrade soon so I can get the latest Windows 10 installed and finally be able to do that Microsoft Game pass which is something I would have liked to do now but Game pass requires the latest Windows 10 to be installed or it is a no go according to MS's requirements.

    Before someone gets on my back about not being patched I was all patched up for about 3 weeks. I did not know MS put the update patches into my system and was wondering my my FPS counts dropped to a degree I actually noticed and why the system was less responsive that it had been in the past when I started digging by using a little program it reported back to me that my performance level was low because it had all of the patches installed. I disabled what I could and ripped the rest of them out of my system and then blocked and I mean 100% blocked MS from doing updates on my system.

    I do updates but I download the ones that are not related to those patches and install them at my choosing. When I switch to AMD Ryzen platform I will install fresh Windows 10 with latest patches as well and finally be able to enjoy the game pass MS offers. BY the way My Sandy Bridge is a i7 2600K@5.1GHz so for those patches to make a 5.1GHz CPU act like a Core2Quad but with Hyper Threading basically seems like they did not put to much effort into the patch fixes or they just worried more about the newer stuff and not really caring about the older stuff because it is not making them any farther money.
  • RSAUser - Tuesday, July 2, 2019 - link

    The amount of BS in that post. You'd have lost maybe 2/3 fps if the game was I/O bound, it wouldn't have made a game unplayable.

    New Windows update of May 2019 released a new version of the specter and other mitigations patch that has supposedly near no difference to without patch, so update.

    Windows 10 1709 had EoL in April 2019 (it was released Oct 2017, W10 has 1.5 years support per major version), you're not getting any security patches.

    Enjoy your tinfoil hat.
  • WaltC - Thursday, July 4, 2019 - link

    Windows microcode patching is always a last resort. I don't like it because if you reinstall Windows you have to reinstall the microcode patches every time, and I'm assuming some Linux distros include the microcode patches as well--same thing applies, of course. Main thing is that if they cannot fix it with a firmware patch it means the windows microcode patch is the only method possible, etc. It is inevitable that at least some of them will cause performance problems at times. But the main reason AMD looks much more attractive than Intel is the simple fact that Zen 2 (3k series) is a much, much newer architecture than what Intel is presently peddling--which because of that doesn't have the vulnerabilities current Intel processors have at the level of the processor itself. Of course, performance is a good reason to move to AMD and avoid all of that tiresome Windows/OS microcode patching! Gawd, yes...;)
  • imaskar - Wednesday, June 26, 2019 - link

    It will behave normally, just give away all your credentials, that's all.
  • Kvaern1 - Thursday, June 27, 2019 - link

    Exactly how are these bugs affecting you ?
    There are literally zero home usercase scenarios I can think of which the SMT bugs affect in any meaningful way.

Log in

Don't have an account? Sign up now