Apr 08, 2021

Same process, same address space Spectre attacks were never resolved on any high-performance (OoO, speculating) CPUs. AFAICT, this attack just adds to the pile of known, and mountain of unknown, vectors.

Far from making AMD look bad, this attack actually makes AMD look good. Consider the limitations:

> The PSF is limited to training about store/load dependencies within the same context. A context is defined by the current values of CPL, ASID, PCID, CR3, and SMM status. Training only occurs if both the store and load execute in the same context. Any time that any piece of the context state changes (e.g. system call) existing training information is flushed. In particular, this flushing occurs on all far control transfers which includes all CPL changes, system call and return, interrupt/exceptions, SMM entry/exit, and VM entry/exit.

> Note that the PSF predictor is partitioned amongst SMT threads so the activity of one SMT thread does not influence the PSF predictions of the sibling thread.

Source: https://www.amd.com/system/files/documents/security-analysis...

It doesn't even implicate SMT, which means AMD's engineers have actually upped their game. (AMD had some SMT issues before, though fewer than Intel.) It's possible that the vector was created knowingly with the calculus that dependable in-process side-channel avoidance isn't viable (not just because of performance, but because of sheer risk of mistakes); and then they put all their effort into ensuring the new speculation wasn't exploitable across security boundaries. Which was the only reasonable thing to expect both before and after Spectre, anyhow.