Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> 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.


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).


Possibly not. Seems like this exploit allows walking memory which would be shared?


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: