AMD Releases Updated Speculative Spectrum Safety Status: Predictive Store Transfer

[ad_1]

The mention of Specter and Meltdown is enough to send shivers down any InfoSec spine. A number of these security vulnerability bundles deal with speculative execution and how a processor can disclose data while speculatively executing code. This week, AMD anticipated the security space by detailing a potential security issue regarding its new Zen 3-based Predictive Store Forwarding feature, designed to improve code performance by predicting dependencies between loads and stores. AMD makes it clear that most users will not need to take action, as the risk to general consumer use of any breach is low and no known code is vulnerable.

Predictions create predilections for data

Modern processors use a number of smart techniques to improve performance. A number of these techniques fall under the rubric of “ speculation ” – at a high level, when a processor is executing code as a simple true / false branch, rather than waiting for the result of that true / false check. comes from memory, it will start to run both branches at the same time. When the true / false result returns from memory, the branch which had the correct answer is kept and the other is destroyed. Modern processors also predict memory addresses in repeating loops, or values ​​in a sequence, by learning what code has already been processed. For example, if your loop increments a load address of 1024 bytes every cycle, by 100e loop, the processor has learned where it expects the next load to come from. This is all pretty smart and allows for a lot of performance.

The downside to these techniques, aside from the additional power consumption required to run multiple branches, is that data flows from both the correct branch and the incorrect branch. This incorrect branch could access data it shouldn’t be supposed to be and store it in caches, where it can be read or accessed by different threads. A malicious attacker could trick the wrong branch into accessing data it shouldn’t. The concept has many layers and is much more complicated than what I’ve presented here, but in any case speculation for performance reasons without considering security can lead to fast but leaky data.

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

Predictive store transfer

This week’s AMD document is a security analysis of its new Predictive Store Forwarding (PSF) feature in Zen 3. PSF identifies execution patterns and commonalities in repeating store / load code, known as storage-to-load transfer name. PSF allows 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 outcome is ultimately needed, then we didn’t have to wait, and the prediction / speculation did its job and provided additional performance.

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

First, the storage-to-load transfer pattern may change unexpectedly. If the store / load pair is based on a fixed dependency model (such as a fixed data step length using an external multiplier), the PSF learns that model and continues. If this dependency suddenly changes or indeed becomes random, the PSF will continue to speculate until it has learned the new dependency model. As it continues to speculate during this time, it has the potential to draw unnecessary data into caches which may be probed by external threads, or the access time to this sensitive data will change for external threads, and this may to be watched.

Second, the PSF can be vulnerable by memory alignment / aliasing of predictions with dependencies. The PSF is designed to operate and track data based on part of the memory address alignment. Therefore, when the speculation between store and load occurs with an alignment, if a dependency is in the mix of that speculation and the dependency ends up not aligning the predicted values, it can lead to incorrect speculation. The data is still valid for speculation that won’t be used, but that’s where the problem lies – that the data may be sensitive or out of memory for the thread in question.

Limits

PSF only occurs in a single thread – the way PSF learns where the next store / load pair should be is individual for each thread. This means that an attack of this nature relies on the underlying code that causes the PSF speculation to venture into memory unintentionally, and cannot be exploited directly by an incoming thread, even on the same core. It might sound somewhat unassailable, but if you’ve ever used a code simulator in a web browser, your code will run 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 whether any of these an effective new context has been created. Context switching also occurs with system calls, also flushing data.

AMD lists that in order to exploit PSF, it requires the store-load pairs to be close to each other in the instruction code. Additionally, the PSF is driven by successive correct branch predictions – a complete false prediction can cause a pipeline flush between the store and the load, removing any potentially harmful data.

Effect on consumers, users and business

AMD (and its security partners) has identified that the impact of PSF exploitation is similar to that of speculative store bypass (Specter v4), and a security issue arises when code implements a security check that can be bypassed. This can happen if a program hosts untrusted code that can influence how other code speculates – AMD cites that a web browser could deliver such an attack, similar to other Specter-type vulnerabilities.

Although similar to other Specter attacks, AMD’s security analysis indicates that an attacker should indeed train a thread’s PSF with malicious code in the same thread context. This is somewhat difficult to do natively, but can be caused by high security accesses. That being said, PSF does not occur in separate address spaces enabled by current hardware mechanisms, such as secure encrypted virtualization. PSF data is flushed if invalid data access occurs.

For the enterprise market, AMD says the security risk is mitigated through hardware-based address space isolation. If an entity does not have a way to isolate address space in its deployment, the PSF can be disabled by setting MSR 48h bit 2 or MSR 48h bit 7 to 1. The only products that would be affected from today’s Ryzen 5000 processors EPYC Milan 7003 processors.

AMD is not currently aware of any code in the wild that could be vulnerable to this type of attack. The security risk is considered low and AMD recommends that most end users see no security risk by leaving the feature enabled, which will always be the default in the future.

The full security analysis document, along with a suggested mitigation for the company, is available at this link.

[ad_2]

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *