AMD microcode and AGESA updates available on several platofrms... time table here: https://www.amd.com/en/resources/product-security/bulletin/a...

Expect to see BIOS and OS updates soon if not already out. I believ Microsoft has already pushed a cumulative that includes some mitigations.

What does 'not applicable' mean in this context? No problems or we don't have plans to fix it? Zen1/1+ doesn't seem present in these charts at all.

Edit: It is actually mentioned if you do something clever like read.

> No µcode patch or BIOS update, which includes the µcode patch, is necessary for products based on “Zen” or “Zen 2” CPU architectures because these architectures are already designed to flush branch type predictions from the branch predictor.

> Instead of flushing the entire branch predictor state, AMD proposed a different mitigation for the Linux kernel. By reducing all returns in the kernel to a single one, it becomes possible to ensure a safe (but still incorrect) branch predictor state each time this return is executed. Keeping previous mitigations in mind, this effectively means that AMD opted to have all indirect branches forcibly mispredict to a benign location, preventing Inception attacks.

So, There will be no decrease in performance or any other performance impact if you are running Linux kernel.

As I understand it, there is likely to be a performance decrease when executing indirect branches within the kernel.

My understanding (which could be incorrect) is that the single return location clobbers the branch predictor's leaked data with static and (attack) worthless data without completely clearing the rest of the prediction cache.

Right, which means the CPU can't effectively predict indirect branches (like calls through function pointers, or certain types of switch statements).

> By reducing all returns in the kernel to a single one, it becomes possible to ensure a safe (but still incorrect) branch predictor state each time this return is executed

I'm way out of my depth here, what does this mean? My naive guess is that they ensure there is a single assembly instruction in the entire kernel that can do a return, and every place that wants to return jumps to that return?

I think there is already an entire Rube Goldberg machine like that in the kernel for spectre mitigation.

It seems that exploits for this are non-trivial:

  In order to exploit vulnerability, an attacker needs to:
  
   - gain local access on the machine
  
   - break kASLR
  
   - find gadgets in the running kernel in order to use them in the exploit
  
   - potentially create and pin an additional workload on the sibling
     thread, depending on the microarchitecture (not necessary on fam 0x19)
  
   - run the exploit

From docs added to the Linux kernel alongside the mitigation for this vulnerability: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

That fact that breaking kASLR is required for this and the considerably complex exploit chain compared to others makes me worry about this a lot less compared to the exploitable-from-JS ones.

I'll wait for some benchmarks to come out from Phoronix or similar and depending on how bad the perf hit is, I will consider disabling mitigations for this on my personal computer.

If someone has gotten a malicious binary running on my machine - even without root permissions - it's already over anyway.

Breaking KASLR is also required for the original Spectre attack (and Inception can break it by itself). In fact, the threat model of Inception is identical to that of original Spectre. Inception may be more complicated, but the requirements are the same.

This is a bad week for speculative execution.

I suspect that in a decade or two we will see speculative execution as we see shared mutable state today: a dangerous trap that should be best avoided in any new designs.

isn’t every attack based on speculative execution actually just an attack over shared mutable state? i.e., if the branch predictions, cache, and so on weren’t both shared and mutable, speculative execution wouldn’t be so problematic?

Indeed. Not just shared, but shared across security domains, e.g. across OS processes, or across the kernel / userspace boundary.

Speculating within one security domain would not be problematic, because anything such speculation allows to glean is already accessible normally. This is sort of similar to having a single reference to a mutable object, which is also safe.

Or the mistake is that we're running different trust domains on the same CPU core.

All the various mitigations have already been very costly (something like a performance loss of 10% on current-gen CPUs?). Getting rid of speculative execution entirely would cost far, far more.

There is state shared between cores too though, at the very least L3, probably IOMMUs, etc. I wouldn’t be entirely surprised if there are issues we haven’t found that exist there.

But the further out you push the shared state, the less it hurts to disable speculation that affects the shared state.

> Or the mistake is that we're running different trust domains on the same CPU core.

It's very hard to not make that mistake. Think of all the websites running in your browser on your laptop. Isolating all those trust domains is going to be quite costly.

I feel like that became apparent with Spectre and Meltdown - they really opened the floodgates. I do wonder if there is some way to have formally proven correctness for speculation - a sort of analogue to the borrow checker in Rust if you like.

I think CPU speculative state needs to be reified, or else we need security domain tagging of speculative state.

Is it possible to break out of a virtual machine and gain access to the hypervisor with this?