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.
New x86 micro-op vulnerability breaks all known Spectre defenses
181–190 of 203 posts
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#182Earlier 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…
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
#183I'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…
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#184Maybe 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
#185I'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…
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
#186This 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.
https://www.researchgate.net/publication/322000263_Fantastic...
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#187This 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.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#188Maybe 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.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#189Earlier 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…
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
#190Earlier 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?
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.