Live data from Hacker News

New x86 micro-op vulnerability breaks all known Spectre defenses

sciencedaily.com

181–190 of 203 posts

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

#181

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

The thing is most project could successfully run on a single dedicated server plus have a one or two spares. There is absolutely no need for a slow virtual nodes. I always thought of those cloud solutions as a clever scam.

If you see them as a scam you're welcome to not use them. There are still colo facilities out there, and if you don't want to use that there are ISPs that will let you connect to the Internet.

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

#182
post #22

Earlier quoted context omitted.

Yes. It could undermine your browser if you allow a malicious site to run JavaScript.

Not really. So far these mostly haven't been able to cross process boundaries, and most browsers have tripled-down on process-sandboxing by this point (iframe sandboxing was the last major push here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if... ) So process-based sandboxing will continue to be the defense here, and process switching will just get a little bit slower as increasingly more caches are…

> So far these mostly haven't been able to cross process boundaries

Actually, most Spectre vulnerabilities, including this one, do cross process boundaries when they are first discovered, and kernel and microcode patches are needed to implement mitigations against this -- typically flushing some cache or something when switching between kernel and userspace. Often these mitigations hurt performance.

> things like Cloudflare's Workers are looking a lot more suspect.

Cloudflare Workers uses a completely different approach to Spectre mitigation, based on slowing down observability of side channels to the point that an attack isn't practical. More details here:

https://blog.cloudflare.com/mitigating-spectre-and-other-sec...

This approach doesn't target specific forms of speculation and therefore tends to work against the whole class of bugs, including ones that haven't been disclosed yet. The down side is that it requires restricting the programming environment including changes that would be backwards-incompatible for browsers, and it certainly wouldn't work at all with native code. Luckily Cloudflare Workers was able to design for these constraints from the start.

I'm the tech lead of Cloudflare Workers, so I may be biased. But, my honest opinion is that the cloud hosts that accept native code are in a much more precarious position than we are.

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

#183

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

It’s perfectly possible, you just can’t take shortcuts, you’ll lose quite a bit of performance. And of course if you really ‘share’ a resource the users are going to know a bit about each other. If each users share grows and shrinks as others are using more or less they are going to know that. But if you don’t want that you could just reserve a fixed part of the resource and they wouldn’t know.

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

#184
This may sound stupid, but the commonality in all these side channel attacks is that high precision time keeping is a non privileged operation.

Maybe it’s time to make clocks a privileged op as a mitigation. Even making execution time non predictable on untrusted code, such as JavaScript?

If precise time keeping is unavailable these become harder to do.

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

#185

I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…

You could very much design and verify that a CPU such that execution of arbitrary code has no observable side effects.

However attempting to do so is multi year, for modern CPUs certainly multi decade project. This is not feasible as long as Moore's Law goes on.

Formal verification of kernels (SEL4) and a micro processors it runs on have been performed together to proof properties.

Large ALU blocks and vector units (such as multipliers) can be formally verified.

However efforts of end-to-end formal verification of entire processors won't happen unless there is demand to justify the huge investment of engineering resources and the market would be fine with chips many years behind.

Unless everyone is running dozens of clients on all their hardware it is cheaper to give everyone their own machine instead of investing the engineering time in to verifying chips. The economic incentives for Intel that selling more machines for isolation brings them more revenue without having to make investments in to decade long verification projects means it is not a mathematical certainty that it can't happen but just an economic one. After all speculative execution is just extra state and extra logic which can be formally verified. After all programs are just bit patterns and all quarters can be addressed in the formalism of Quantified Boolean Formulas.

But nobody is gonna undo 20 years of performance. You will just be told to buy more machines to isolate workloads.

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

#186
post #184

This may sound stupid, but the commonality in all these side channel attacks is that high precision time keeping is a non privileged operation. Maybe it’s time to make clocks a privileged op as a mitigation. Even making execution time non predictable on untrusted code, such as JavaScript? If precise time keeping is unavailable these become harder to do.

It is surprisingly difficult to make timekeeping unavailable. There are many methods, besides the official timer APIs, to get timing - as outlined in the paper "Fantastic Timers and where to find them" from TU Graz:

https://www.researchgate.net/publication/322000263_Fantastic...

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

#187

This had to come. The only fix will be to add a BIOS setting for Speculative Access or no speculative access. Gamers all turn it on, with a machine patched, that runs nothing but their game. Everyone else, like browsing the web, off. Look for a encoded binary java script exploit that will own any speculative access system. Its coming too, just like this paper would eventually come.

This is not feasible. Not everyone has multiple computers. And not everyone wants to use different computers for different things, or take the effort to muck around in the (often mazelike) bios settings.

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

#188
post #92

Maybe EPIC [1] architectures need a revival. Rely on compilers to take advantage of explicit instruction-level parallelism, and keep the CPU dumb. [1] https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...

That failed for good reasons. Itanium processors ended up using out of order execution and speculation just like everyone else, because the compilers just don't have enough information compared to an out of order execution engine.

From Poulson onwards anyway. https://www.realworldtech.com/poulson/

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

#189

Earlier quoted context omitted.

It sounds like a dream, but going back towards interpreted JS instead of JIT may finally stem the insanity of bloat that JS has evolved in an environment of increasingly fast implementations.

The problem of Javascript bloat doesn't have a technical solution. Javascript bloat exists because of a social problem: the guy who fixes the corporate webpage's javascripts is called a "webdesigner", and "webdesigners" are the lowest rung on the corporate IT ladder, maybe only a bit above first-tier techsupport. If you want to make some sort of career you need to upgrade from "webdesigner" to "frontend developer", a…

>Javascript bloat exists because of a social problem

JS bloat exists because HTML Working Group along with the whole industry believes JS is the solution to everything. They believe everything on the web should be Web Apps, and completely neglect Web Page development. It was only in the recent 2 two years did we start seeing discussions to reverse course.

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

#190

Earlier quoted context omitted.

turing architecture - code and data are handled the same way. harvard architecture - code and data are separate things

Isn't that Von Neumann architecture vs. Harvard?

That's not what the poster is talking about though.

They're talking Von Neumann with a special "blessed" tooling written to not produce behaviors that would let users do nefarious things. They want to reduce the space of possible computations from arbitrary to "only these patterns which are provably safe".

Essentially, they want to hobble the user (malicious or not) and force good behavior by giving them tools that are incompatible with malicious behavior. They want Asimov's Three Laws of Robotics for computation.

The issue being, you run into Halting problem real fast when trying to make that blessed toolset. How does it recognize malicious code or bad series of individually benign, but collectively malignant opcodes? Remember, side channels like Spectre and Meltdown boil down to timing how long it takes for a computer to say "no", and then for you to access a piece of data you know should only be cached if the conditional that was preempted by an access violation was one value or another.

That is, start timer -> run (expected to raise access violation) conditional, branch speculative load -> access check -> exception -> check for result value in cache -> stop timer -> rinse -> repeat

Each of those is a benign command that could be sprinkled in anywhere. Collectively, they are a side-channel. You could still make variations of the same setup by tossing in junk values in between the necessary steps that would avoid this blessed tooling's (assumed) unwavering pattern recognition. I wouldn't actually use a compiler to stop this. You'd use a static analyzer to recognize these combinations; and even then, there's a lot of timer -> thing -> timer stop -> check programs that aren't malicious at all out there.

The answer with computers has been "if it absolutely must remain secret, implement security at a higher level than just the computer". Everyone should know that if you've got access, the computer will do what it's told to do.

The poster's suggestion is a pipe dream; and a dangerously seductive one at that, since anytime you hear from the "Trusted/Secure Computing" crowd, it almost always means someone wants to sacrifice everyone else's computing freedoms so they can write something they can pretend to guarantee will work.

Sorry, the cynicism leaked in a bit at the end there; but I have yet to see a security initiative that does anything but make life miserable for everyone except security people. I'll put up with some unsafe behavior in order to keep the barrier to entry low for the field in general; and accept the cost of more rigid human centric processes to make up for the indiscretions of the machine. Keep abstraction leakage in check.

Post reply on HN