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?
New x86 micro-op vulnerability breaks all known Spectre defenses
21–30 of 203 posts
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#22Question: 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?
Yes. It could undermine your browser if you allow a malicious site to run JavaScript.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#23I don't understand this at all; I didn't think the mico-op cache was visible to code written for the x86 ISA at all. Can anyone explain to an idiot (me) how something in micro-op cache can become visible to the outside world?
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…
so something say, sandboxed (like in a browser running webassembly) could get at non-sandboxed data?
Or something in one VM getting at data from a different VM?
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#24Question: 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?
Yes. It could undermine your browser if you allow a malicious site to run JavaScript.
Spectre could too, but again, my point was that I didn't hear of actual attacks on people in the wild, at least not on any scale that seemed to make the news. Is there a reason to believe this will be different?
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#25I'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 what that spells for cloud hosting providers - maybe they have to buy a lot more CPUs so every client can have their own, or commission a special "shared" SKU of CPU that doesn't have any speculative execution - but I know for me, if I have untrusted code running on my CPU, I've already lost. I could then care less about information leakage between threads.
We're going to wind up undoing the last 20 years of performance gains in the name of 'security', and it scares me.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#26You cannot realistically make a CPU invulnerable to performance analysis
And you don't need to.
There is really very few uses for real multi-system vs multi-process shared systems.
Take a look on that whole "cloud" thing.
All people I knew who worked in cloud hosting tell that most system are ridiculously overprovisioned, effectively nullifying any economic justification for a shared system
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#27I'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…
> 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.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#28Earlier 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…
so something say, sandboxed (like in a browser running webassembly) could get at non-sandboxed data? Or something in one VM getting at data from a different VM?
There are examples of straight JavaScript exploits that allow a website to read memory from anywhere in the process its code is running in.
https://cacm.acm.org/magazines/2020/7/245682-spectre-attacks...
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#29You cannot realistically make a CPU invulnerable to performance analysis And you don't need to. There is really very few uses for real multi-system vs multi-process shared systems. Take a look on that whole "cloud" thing. All people I knew who worked in cloud hosting tell that most system are ridiculously overprovisioned, effectively nullifying any economic justification for a shared system
One day, when margins shrink for cloud compute, we'll see less and less overprovisioning...
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#30I'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.