4 ms·

I wonder if there's similar gaps in AMD hardware? Seems like speculative execution is simply an extremely hard to patch vulnerability in a share processor space

by rtkwe 1y ago

I wonder if there's similar gaps in AMD hardware? Seems like speculative execution is simply an extremely hard to patch vulnerability in a share processor space so I wonder how AMD has avoided it.

tmoertel 1y ago
According to the authors' blog post: > Does Branch Privilege Injection affect non-Intel CPUs? > No. Our analysis has not found any issues on the evaluated AMD and ARM systems. Source: https://comsec.ethz.ch/research/microarch/branch-privilege-injection/ https://comsec.ethz.ch/research/microarch/branch-privilege-i...
- __turbobrew__ 1y ago
  Intel is getting kicked while it is down.
pdpi 1y ago
The short of it is that AMD haven’t “avoided it”. Speculative execution side channels aren’t one vulnerability but rather a whole family of vulnerabilities. This particular one is (apparently) Intel-only, same as Meltdown was, but AMD was also vulnerable to the original Spectre.
bee_rider 1y ago
Pedantically, speculative execution isn’t the vulnerability, it is a necessary mechanism for every high-performance CPU nowadays (where “nowadays” started, like, around the turn of the century). However, bugs and vulnerabilities in speculative execution engines are very widespread because they are complicated. There are probably similar bugs in AMD and ARM, I mean how long did these bugs sit undiscovered in Intel, right? Unfortunately the only real fix is to recognize that you can’t isolate code running on a modern system, which would be devastating to some really rich companies’ business models.
- fc417fc802 1y ago
  > the only real fix is to recognize that you can’t isolate code running on a modern system Does pinning VMs to hardware cores (including any SMT'd multiples) fix this particular instance? My understanding was that doing that addressed many of the modern side channel exploits. Of course that's not ideal, but it's not too bad in an era where the core count of high end CPUs continues to creep upwards.
  - everfrustrated 1y ago
    Possibly not. Seems like this exploit allows walking memory which would be shared?
    - fc417fc802 1y ago
      But can you exfiltrate memory without it being accessed on the core you're running on? I thought branch predictors were a one-per-physical-core sort of thing and that this class of side channel attack leaked something being done on the same core in a different privilege domain.
  - vlovich123 1y ago
    If this allows reading kernel memory, then your VMs could read the host kernel anyway & any security keys contained therein (& that’s assuming pinning cores limits the exploit to memory being accessed by other CPUs on the same core which generally has not been true of side channel attacks as far as I’m aware).
- rtkwe 1y ago
  I meant that it's a feature that's hard to implement in a way that delivers the performance gains without creating vulnerabilities like this one.
quotemstr 1y ago
The solution to this particular vulnerability is intuitive to me: snapshot the current privilege level when we enqueue a branch predictor update and carry that snapshot along with the update itself as it flows through the processor's internal buffers. Same problem you might have in software and the same solution, yes?
- wbl 1y ago
  That actually doesn't work. The evaluation of the branch condition may be at some point far away from where the privilege update is recognized and executed. There is no current state to update, it's only recognized in retrospect what the state was. And carrying along data is pricey in a CPU: the instruction pointer isn't even available because of this. You could say we only update the predictor at retirement to solve this. But that can get a little dicy also: the retirement queue would have to track this locally and retirement frees up registers, better be sure it's not the one your jump needs to read. Doable but slightly harder than you might think.

by rtkwe 1y ago

I wonder if there's similar gaps in AMD hardware? Seems like speculative execution is simply an extremely hard to patch vulnerability in a share processor space so I wonder how AMD has avoided it.

tmoertel 1y ago

According to the authors' blog post: > Does Branch Privilege Injection affect non-Intel CPUs? > No. Our analysis has not found any issues on the evaluated AMD and ARM systems. Source: https://comsec.ethz.ch/research/microarch/branch-privilege-injection/ https://comsec.ethz.ch/research/microarch/branch-privilege-i...

__turbobrew__ 1y ago
Intel is getting kicked while it is down.

pdpi 1y ago

The short of it is that AMD haven’t “avoided it”. Speculative execution side channels aren’t one vulnerability but rather a whole family of vulnerabilities. This particular one is (apparently) Intel-only, same as Meltdown was, but AMD was also vulnerable to the original Spectre.

bee_rider 1y ago

Pedantically, speculative execution isn’t the vulnerability, it is a necessary mechanism for every high-performance CPU nowadays (where “nowadays” started, like, around the turn of the century). However, bugs and vulnerabilities in speculative execution engines are very widespread because they are complicated. There are probably similar bugs in AMD and ARM, I mean how long did these bugs sit undiscovered in Intel, right? Unfortunately the only real fix is to recognize that you can’t isolate code running on a modern system, which would be devastating to some really rich companies’ business models.

fc417fc802 1y ago
> the only real fix is to recognize that you can’t isolate code running on a modern system Does pinning VMs to hardware cores (including any SMT'd multiples) fix this particular instance? My understanding was that doing that addressed many of the modern side channel exploits. Of course that's not ideal, but it's not too bad in an era where the core count of high end CPUs continues to creep upwards.
- everfrustrated 1y ago
  Possibly not. Seems like this exploit allows walking memory which would be shared?
  - fc417fc802 1y ago
    But can you exfiltrate memory without it being accessed on the core you're running on? I thought branch predictors were a one-per-physical-core sort of thing and that this class of side channel attack leaked something being done on the same core in a different privilege domain.
- vlovich123 1y ago
  If this allows reading kernel memory, then your VMs could read the host kernel anyway & any security keys contained therein (& that’s assuming pinning cores limits the exploit to memory being accessed by other CPUs on the same core which generally has not been true of side channel attacks as far as I’m aware).
rtkwe 1y ago
I meant that it's a feature that's hard to implement in a way that delivers the performance gains without creating vulnerabilities like this one.

quotemstr 1y ago

The solution to this particular vulnerability is intuitive to me: snapshot the current privilege level when we enqueue a branch predictor update and carry that snapshot along with the update itself as it flows through the processor's internal buffers. Same problem you might have in software and the same solution, yes?

wbl 1y ago
That actually doesn't work. The evaluation of the branch condition may be at some point far away from where the privilege update is recognized and executed. There is no current state to update, it's only recognized in retrospect what the state was. And carrying along data is pricey in a CPU: the instruction pointer isn't even available because of this. You could say we only update the predictor at retirement to solve this. But that can get a little dicy also: the retirement queue would have to track this locally and retirement frees up registers, better be sure it's not the one your jump needs to read. Doable but slightly harder than you might think.