Earlier quoted context omitted.
I'm simplifying a bit (edit: quite a bit =]), but the way these attacks work is generally by exploiting the difference in timing between something being in cache, and something not being in cache. Or some resource being contended vs not contended. If something is in cache, and you also have access to that cache, accessing that thing will be fast and few CPU resources will be used. So you can tell that something is in…
The fix is simple, don't allow access to clocks or timing information in anything other than the microkernel that runs the OS.
New x86 micro-op vulnerability breaks all known Spectre defenses
41–50 of 203 posts
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#42Earlier quoted context omitted.
> if I have untrusted code running on my CPU, I've already lost Don’t forget about JavaScript, a common way for people to run untrusted code on their computers. Not all of micro-architectural data sample are exploitable in JavaScript, but some are.
Yeah, JS is the only hairy part. I considered mentioning it, since I know it was going to come up. But luckily, all I've seen so far are basic demos (like leaky.page) that read data from a carefully-crafted array that the page itself populated. I've yet to be convinced that you could realistically exfiltrate meaningful data at any sort of scale with in-browser JS, especially now that more blatant bugs like Meltdown a…
In other words, if I choose a process on my system at random, and dump a few dozen bytes from it, I can technically claim to have leaked some data; but the use of that data to an attacker likely depends strongly on factors which are outside of the attacker's control. It's somewhat like finding a (real-world) key on the ground: you theoretically now have access to something you shouldn't have, but you have next to no idea what that something is.
But I feel confident that these issues are purely academic and, while interesting, serve more to provide content for PhD theses than represent urgent hazards on the web.
They also provide content for sensationalist clickbait articles and fuel the paranoia that drives society towards authoritarianism and furthers the war on general-purpose-computing, which IMHO is a much bigger issue to worry about.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#43Earlier quoted context omitted.
Even putting aside security aspects aside, in general I've been seeing research pop up over the years criticizing SMT's performance claims of ~30%. Hell, even Amazon's Graviton CPUs don't have it (though I'm sure that's a product of being ARM derived rather than a design decision).
ARM vendors must be feeling pretty good about themselves yeah, but if you take AMD's cores... SMT might not be a huge win in every benchmark, but you just can't keep that wide backend fed from a single hyperthread (at least I can't!). So turning SMT off is at the least wasted potential for those cores, the way they've been designed
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#44The solution will be "do not share the micro-op cache between different address spaces". Which for old hardware will translate to "flush the micro op cache every time the address space changes". I would guess that can be done with a microcode update and that the performance hit wont be too massive.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#45Earlier quoted context omitted.
One day, when margins shrink for cloud compute, we'll see less and less overprovisioning...
I usually end up over provisioning because I need something that is billed along with CPU; for example I have super good C or Go code to run proxies on, they use like 2% of the CPU when they max out the network connection. I add more so the bandwidth goes up.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#46There are separate micro op caches per core however they are typically shared among hyperthreads. I wonder if this could be another good reason for cloud vendors to move away from 1vCPU = 1 hyperthread to 1vCPU = 1 core for x86 when sharing machines (not that there weren't enough good reasons already).
Why would this be an issue for machines on the cloud? If someone can upload binaries to your machine you have bigger problems, no?
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#47There are separate micro op caches per core however they are typically shared among hyperthreads. I wonder if this could be another good reason for cloud vendors to move away from 1vCPU = 1 hyperthread to 1vCPU = 1 core for x86 when sharing machines (not that there weren't enough good reasons already).
Why would this be an issue for machines on the cloud? If someone can upload binaries to your machine you have bigger problems, no?
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#48Earlier quoted context omitted.
The fix is simple, don't allow access to clocks or timing information in anything other than the microkernel that runs the OS.
That would break so many things.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#49Earlier quoted context omitted.
>The safe execution of any untrusted Turing complete code is a pipe dream. The safe execution of any code requires an operating environment that never trusts the code with more than the least privilege required to complete a task. It has worked in mainframes that way for decades. The IT zeitgeist these days makes me sad. Things can be better, but almost everyone is pushing in counterproductive directions, or has give…
> The safe execution of any code requires an operating environment that never trusts the code with more than the least privilege required to complete a task. It has worked in mainframes that way for decades. It has nothing to do with any OS level security features. We are talking about things happening below the level of what software can see. You just cannot see any sign of such attack by looking at any register the…
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#50OpenBSD disabled HT by default.