The mention of Spectre and Meltdown is enough to send chills down any InfoSec spine. A number of these batches of security vulnerabilities deal with speculative execution, and how a processor might leak data while executing code in a speculative manner. This week AMD has pre-empted the security space by detailing a potential security concerns regarding its new Zen 3-based Predictive Store Forwarding feature designed to improve code performance by predicting dependencies between loads and stores. AMD is clear to point out that most users will not need to take any action, as the risk for general consumer use to any breach is low, and no known code is vulnerable.

Predictions Create Predilections for Data

Modern processors use a number of clever techniques to improve performance. A number of those techniques come under the heading of ‘speculation’ – at a high level, when a processor runs code like a simple true/false branch, rather than wait for the result of that true/false check to come in from memory, it will start executing both branches at once. When the true/false result comes back from memory, the branch that had the right answer is kept, and the other is destroyed. Modern processors also predict memory addresses in repetitive loops, or values in a sequence, by learning what code has already been processed. For example, if your loop increments a load address by 1024 bytes every cycle, by the 100th loop, the processor has learned where it expects the next load to come from. It’s all rather clever, and enables a lot of performance.

The downside of these techniques, aside from the extra power consumption needed to execute multiple branches, is the fact that data is in flow from both the correct branch and the incorrect branch at once. That incorrect branch could be accessing data it shouldn’t meant to be and storing it in caches, where it can be read or accessed by different threads. A malicious attacker could cause the incorrect branch to access data it shouldn't be accessing. The concept has lots of layers and is a lot more complicated than I’ve presented here, but in any event, speculation for the sake of performance without consideration to security can lead to fast but leaky data.

For the most part, the whole industry including AMD, Intel, and Arm, have been susceptible to these sort of side-channel attacks. While Meltdown style attacks are more isolated to Intel microarchitectures, Spectre-type attacks are industry wide, and have the potential to leak user memory even in browser-like scenarios.

Predictive Store Forwarding

AMD’s document this week is a security analysis on its new Predictive Store Forwarding (PSF) feature inside Zen 3. PSF identifies execution patterns and commonalities in repeated store/load code, known as store-to-load forwarding. PSF enables the thread to speculate on the next store-to-load result before waiting to see if that result is even needed in the first place. If the result is eventually needed, then we haven’t needed to wait, and the prediction/speculation has done its job and enabled extra performance.

AMD has identified that its PSF feature could be vulnerable in two ways.

First, the pattern of the store-to-load forwarding could change unexpectedly. If the store/load pair is based on a fixed dependency pattern (such as a fixed data stride length using an external multiplier), the PSF feature learns that pattern and continues. If that dependency suddenly changes, or becomes effectively, random, the PSF feature will continue to speculate until it has learned the new dependency pattern. As it continues to speculate during this time, it has the potential to draw unneeded data into the caches which can be probed by external threads, or the access time to that sensitive data will change for external threads, and this can be monitored.

Second, PSF can be vulnerable through memory alignment / aliasing of predictions with dependencies. The PSF is designed to work and track data based on a portion of memory address alignment. As a result, when the store-to-load speculation occurs with an alignment, if a dependency is in the mix of that speculation and the dependency ends up not aligning the predicted values, this might result in incorrect speculation. The data is still valid for a speculation that won’t be used, but therein lies the issue – that data might be sensitive or outside the memory bounds of the thread in question.

Limitations

PSF only occurs within a singular thread – how PSF learns where the next store/load pair should be is individual to each thread. This means that an attack of this nature relies on the underlying code causing the PSF speculation to venture into unintended memory, and cannot be exploited directly by an incoming thread, even on the same core. This might sound as if it becomes somewhat unattackable, however if you have ever used a code simulator in a web-browser, then your code is running in the same thread as the browser.

PSF training is also limited by context – a number of thread-related values (CPL, ASID, PCID, CR3, SMM) define the context and if any one of these is changed, the PSF flushes what it has learned starts a new as an effective new context has been created. Context switching also occurs with system calls, flushing the data as well.

AMD lists that in order to exploit PSF, it requires the store-to-load pairs to be close together in the instruction code. Also the PSF is trained through successive correct branch predictions – a complete mis-prediction can cause a pipeline flush between the store and the load, removing any potential harmful data.

Effect on Consumers, Users, and Enterprise

AMD (and its security partners) has identified that the impact of PSF exploitation is similar to Speculative Store Bypass (Spectre v4), and a security concern arises when code implements security control that can be bypassed. This might occur if a program hosts untrusted code that can influence how other code speculates – AMD cites a web browser might deliver such an attack, similar to other Spectre-type vulnerabilities. 

Despite being similar to other Spectre attacks, AMD’s security analysis states that an attacker would have to effectively train the PSF of a thread with malicious code in the same thread context. This is somewhat difficult to do natively, but could be caused through elevated security accesses. That being said, PSF does not occur across separate address spaces enabled through current hardware mechanisms, such as Secure Encrypted Virtualization. The PSF data is flushed if an invalid data access occurs.

For the enterprise market, AMD is stating that the security risk is mitigated through hardware-based address space isolation. Should an entity not have a way for address space isolation in their deployment, PSF can be disabled though setting either MSR 48h bit 2 or MSR 48h bit 7 to a 1. The only products that would be effected as of today are Ryzen 5000 CPUs and EPYC Milan 7003 CPUs.

AMD is currently not aware of any code in the wild that could be vulnerable to this sort of attack. The security risk is rated as low, and AMD recommends that most end-user customers will not see any security risk by leaving the feature enabled, which will still be the default going forward. 

The full security analysis document, along with a suggested mitigation for enterprise, can be found at this link.

POST A COMMENT

63 Comments

View All Comments

  • casperes1996 - Tuesday, April 13, 2021 - link

    That's incredibly messed up by Intel Reply
  • mrvco - Thursday, April 8, 2021 - link

    Over the years, any crash and/or stability issues on my WinTel machines were always through the lens of Windows. So in retrospect, I would have an incredibly difficult time pointing the finger at the underlying Intel hardware components rather than the device drivers, OS, etc. It seems easier to isolate hardware-specific issues now that Windows is 'better' and Linux is a viable desktop OS alternative. Reply
  • WaltC - Thursday, April 8, 2021 - link

    Guess you are too young to recall the Intel Pentium(s) errata (bugs)...;)...every CPU ever made has bugs, doesn't matter who makes it. Workarounds exist for every one, IIRC. BTW, the usual teething period for new-architecture CPUs (the time it takes for the motherboard vendors to correctly integrate AMD AGESAs into their motherboard code is usually anywhere from six months to one year.) Same exact thing is true for new architecture Intel CPUs (except they have their own name for issuing vendor bios updates, of course.) You won't have seen that sort of thing from Intel for at least the last six years because Intel hasn't shipped a brand-new ground-up architecture in all of that time (while AMD has shipped three (3) new architectures in the same period)--teething on these old Intel architectures has already been done, with one major caveat. Win10 updates still routinely include Intel-only microcode patching for security holes which is not applied to Win10 if an AMD CPU is present. I forget the last comparative count, but it is something like dozens of OS microcode patches and bios fixes for the current Intel CPU architectures compared to 2-3 for Ryzen. The amount of security patching Intel has to do is an excellent indicator of just how old the current Intel architectures actually are. And if you ever reinstall Win10 on those Intel CPUs you have to reapply all of those microcode patches through Windows update all over again. Reply
  • schizoide - Thursday, April 8, 2021 - link

    My first computer was an Apple ][c, so I've been around awhile. I don't recall any intel CPU causing random crashes multiple times per day. Perhaps it happened, and they didn't take 3 months to fix it.

    Not to imply intel CPUs are perfect, the C2000 bug in particular was deadly, but nothing like that in their core desktop and mobile offerings.
    Reply
  • Spunjji - Thursday, April 8, 2021 - link

    First 1.13Ghz Pentium III Reply
  • Smell This - Thursday, April 8, 2021 - link


    I guess everyone has forgotten about the Intel Workstation OR840 motherboard
    ATX - Slot 1 - i840 __ 2P with RDRAM. I still have a new one in the 'bag'

    https://www.anandtech.com/show/420/3
    Reply
  • Spunjji - Thursday, April 8, 2021 - link

    "ALL the time"
    Nonsense. Intel shills gotta work harder since Rocket Lake exploded on the pad.
    Reply
  • Samus - Friday, April 9, 2021 - link

    True that Intel is no saint for QA, they've had several CPU and chipset recalls where AMD hasn't (outside of GPU's and a very isolated Opteron stepping nearly 2 decades ago) though lets be honest nForce4 should have been recalled but that wasn't really on AMD.

    Coincidentally nForce4's issues are relevant to one of Intel's major recalls in that they both had SATA corruption issues. Of course Intel recalled the Z68 chipset.

    But overall Intel's issues are significantly more substantial than AMD's as Intel's often result in recalls where AMD's just involve pissed off OEM's and end users that eventually get a soft-patch.
    Reply
  • Alexvrb - Sunday, April 11, 2021 - link

    I've had nForce 4 boards that were bulletproof (an affordable Epox comes to mind) and ones that were absolutely garbage (DFI Lanparty something or another with an NF4 Ultra). A lot of it came down to board designs and how far they pushed it.

    Oh the promised hardware-accelerated firewall was a complete fail. Hardware bugs made it basically unfixable and unusable. Which was a shame, as when I first put together a socket 939 system it was a single core machine. Not that it mattered in the longer run as I dumped the never-quite-stable Lanparty for a cheaper Epox with a standard NF4, and later got a good deal on an FX-60 that served me well for some time.
    Reply
  • tamalero - Friday, April 16, 2021 - link

    Id rather have fixable bugs than exploits that hinder performance severely. Reply

Log in

Don't have an account? Sign up now