Live data from Hacker News

New x86 micro-op vulnerability breaks all known Spectre defenses

sciencedaily.com

41–50 of 203 posts

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#41
post #9

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.

That would break so many things.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#42

Earlier 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…

Indeed, I've been feeling indifferent about all these timing sidechannels ever since the very first ones (Spectre/Meltdown). The PoCs have not been particularly convincing to me, given that they are extremely contrived and rely on knowing the exact details of the system being exploited to such an extent that someone with those details would be better off with other ways in, and assumes those details haven't changed at all during the amount of time required to do the attack --- the nature of these side-channels is such that even the smallest change in environment can completely change the results.

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

#43
post #19

Earlier 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

Apple Firestorm is even wider but it doesn't have SMT. I guess they just don't care.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#44

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

[deleted]

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#45
post #31

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

This. I run into this all the time with WebRTC infrastructure. My SFUs run out of bandwidth long before they’re at 100% CPU. It’d be great if I could easily provision VMs based on bandwidth, but of course cloud providers are always real coy and say things like “this VM size class has Medium bandwidth, but this one has 25Gbps, no we won’t say which of those is bigger.”

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#46

There 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?

Because the cloud is designed around people uploading binaries to your machine -- it is a basic principle of how services are allocated. When you go to AWS an spin up an EC2 instance, you don't get a machine to yourself. You get a VM running with many other peoples VMs on some arbitrary server in one of their data centers.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#47

There 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?

[deleted]

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#48
post #41

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

Proper multi-level security doesn't allow access to the clock in anything other than the top level. You could just have a monotonically counter that is periodically synced to reality every minute or two.

Re: New x86 micro-op vulnerability breaks all known Spectre defenses

#49
post #39

Earlier 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…

These are timing attacks, if you can guarantee code runs deterministically, and deny access to timing information, you can defeat the attack.
Post reply on HN