Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New x86 micro-op vulnerability breaks all known Spectre defenses

sciencedaily.com

Post reply on HN
Print view View original

71–80 of 203 posts

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

#71

Post by xucheng »

mikewarot wrote: post #38
tux3 wrote: 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.

You don't need OS to build a very precise clock for the purpose of exploiting timing attack. That's why SharedArrayBuffer[1] is disabled in all browsers.

Moreover, not every side channel attack relies on timing attack.

For interested readers, there is a paper titled "Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript", which discussed a variety of ways to build high resolution clocks.

[1]: https://security.stackexchange.com/questions/177033/how-can-...

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

#72

Post by hinkley »

paulmd wrote: post #57
akersten wrote: post #25

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…

I've been saying since this initially came up that big.LITTLE is the long-term solution for this. In the grand scheme of things, high-intensity tasks are only infrequently high-security tasks - those two sets of workloads are mostly disjoint. So the long-term solution is to have "fast cores" and "secure cores". The fast cores can have all the OoO, speculation, all of that good stuff. That's where you run anything tha…

> It's probably better to get them fully out of the "normal" cache hierarchy as well.

I can’t seem to shake the notion that this idea of transparent, multi-level caching might have to go away too. That cache shared between cores may have to morph into a layer of chip-local memory that you allocate imperatively. It’s possible that languages like Rust or VMs like the Beam could either adapt to such hardware with fewer problems, or even leverage it. We keep trying to pretend like memory is flat but now we’re up to 3-4 layers of cache and memory banks. How much longer can you torture that abstraction?

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

#73

Post by userbinator »

baybal2 wrote: post #34
MarkSweep wrote: post #27

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.

Chrome had 7 exploits caught in the wild within 7 weeks in 2020. I believe it is going towards JIT being disabled, or most severely limited.

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.

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

#74

Post by jimmaswell »

dataflow wrote: post #21

Question: How relevant are these for the average person? I know these matter for things like shared hosting, but I've yet to hear of an actual exploit in the wild that ordinary people have been attacked by, even with Spectre defenses turned off. Should normal people be worried about this?

I personally disable spectre/meltdown mitigations for performance. I don't think any of it is very important for my use cases and I don't leave sketchy websites open for hours on end to give them a chance to make use of the exploits.

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

#76

Post by elihu »

baybal2 wrote: post #30
akersten wrote: post #25

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 are completely correct. The safe execution of any untrusted Turing complete code is a pipe dream. You, at least, need a clean sheet CPU design starting from ISA, and basic logic operations formally validated against instruction level analysis to have a fighting chance. But even such chip do get pwned, as shown by key recovery from credit cards in the wild.

> The safe execution of any untrusted Turing complete code is a pipe dream.

I don't think that's true. It's not turing completeness that's the real problem here. It's that software usually has access to accurate timing information, whether it's via RDTSC, gettimeofday(), or sharing memory with another thread that does things that take a predictable amount of time. If a program has no notion of current time and cannot measure how long something takes, then a lot of those side channel attacks no longer work. (Note that this precludes using styles of threading that have nondeterministic results, but it doesn't preclude using styles of threading that are deterministic, like Haskell's parMap.)

I do think maybe we should move away from the model of "let's let people run programs comprised of arbitrary instructions on their computers, and build all our security around keeping programs from reading and writing things they shouldn't" to a model of "all programs running on this computer were compiled by a trusted compiler, and our security is based on the compiler disallowing certain unsafe constructs". This is sort of analogous to web browsers running javascript in a sandbox, or running eBPF in the Linux kernel.

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

#77

Post by titzer »

xucheng wrote: post #71
mikewarot wrote: post #38

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.

You don't need OS to build a very precise clock for the purpose of exploiting timing attack. That's why SharedArrayBuffer[1] is disabled in all browsers. Moreover, not every side channel attack relies on timing attack. For interested readers, there is a paper titled "Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript", which discussed a variety of ways to build high reso…

SharedArrayBuffer is not disabled in all browsers. It was briefly disabled at disclosure time of the first Spectre vulnerabilities, but as browsers moved to site isolation (one process per origin), they have reenabled it.

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

#79

Post by titzer »

mikewarot wrote: post #48
jeffbee wrote: post #41

Earlier quoted context omitted.

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.

You can construct a high resolution timer from shared mutable memory and multiple threads. It's simple. One thread increments a counter, and the other thread reads it.

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

#80

Post by userbinator »

derekp7 wrote: post #46
secondcoming wrote: post #20

Earlier quoted context omitted.

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.

You get a VM running with many other peoples VMs on some arbitrary server in one of their data centers.

Doesn't that make it even harder to do any sort of specific attack on anything? From what I understand, these side-channel attacks depend on being able to predict the addresses you'll read from and an idea of what you're after as well as a stable environment in which enough timing information can be collected, and any small changes in the environment will mean you can start reading something completely different without even knowing; a CPU that could be running literally who-knows-what at any time seems like it wouldn't let you collect much in the way of coherent data, and of course the VM you're doing it from could itself be moving uncontrollably across CPUs.

Post reply on HN