The CPU needs to make the overheard signals look just like random noise. A cheap XOR-stream (compare 2FA like Google Authenticator, or the remote in your car keys) should cover that.
New x86 micro-op vulnerability breaks all known Spectre defenses
111–120 of 203 posts
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#112I'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…
Will this even be an issue when we have CPUs with hundreds/thousands of cores that can just sandbox processes to their own set of cores/cache with exclusive unshared memory?
I think this idea could be taken further: just build physical machines with lower capacity (RAM, cores), rather than filling data-centers with top-spec hardware then dividing them up with virtualisation. On the face of it at least, this seems like an idea worth taking seriously. With the right form-factor, I imagine it shouldn't even have much of an impact on space efficiency or power efficiency. Perhaps the CPU companies just aren't interested in making such hardware?
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#113Earlier 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…
> The problem of Javascript bloat doesn't have a technical solution.
It would go away in short order if Google rankings severely penalised it.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#114The CPU needs to make the overheard signals look just like random noise. A cheap XOR-stream (compare 2FA like Google Authenticator, or the remote in your car keys) should cover that.
Well, some of these attacks exploit the actual values present in the memory, not their stored representations. Therefore it would not matter how you encode them on the way, right?
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#115Earlier quoted context omitted.
>In the grand scheme of things, high-intensity tasks are only infrequently high-security tasks - those two sets of workloads are mostly disjoint. The most intense thing my phone does is decrypt my password database, and it does this dozens of times a day.
I’m fairly sure that all around the GUI is way more intense than that.
Running argon on 6 cores with 64 MB of memory for 50 iterations is more intense than 2D rendering. The CPU runs full tilt for about 2 seconds.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#116Is ARM so much better? I can migrate my AWS hosts.
Separate micro-op cache per core, and no hyperthreading, so ARM would seem better equipped to defend against this.
Good to know. This new era of aggressive hardware flaw exploitation has me motivated to leverage my mobility and flexibility to evade. I don't think I have a better strategy.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#117Earlier quoted context omitted.
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…
>In the grand scheme of things, high-intensity tasks are only infrequently high-security tasks - those two sets of workloads are mostly disjoint. The most intense thing my phone does is decrypt my password database, and it does this dozens of times a day.
It's hard for me to believe that you are typical of the rest of the world.
My guess is that one Tiktok video consumes far more CPU cycles than decrypting dozens of passwords.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#118Earlier 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…
> 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.
Only PoC says very little. If I were head of a nation state APT I'd look into exploiting this because attack surface of JS is high. I'd only use it targeted, for example on Microsoft Azure team as outlined in Darknet Diaries #78.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#119Earlier quoted context omitted.
The performance claims are true for all the worst reasons. Let's say you can queue up 100 instructions. This yields the following 1 port 100% of the time 2 ports 60% of the time 3 ports 30% of the time 4 ports 10% of the time 5 ports 2% of the time Increasing the buffer to 200 instructions yields the following 2 ports 80% of the time 3 ports 40% of the time 4 ports 15% of the time 5 ports 4% of the time As in that ma…
The memory latency hiding also works with 2-way SMT. I worked on a networking software doing per packet session lookup in large hash tables. SMT with a Sandybridge core in this application gave 40% better performance which is higher than usually mentioned. So for memory bound (as in cache misses) applications, SMT is a boon.
I tested this some years ago on a raytracer, and got a tad over 50% more speed when enabling HT compared to disabling it.
As you say, the ray tracer did a lot of cache missing , interspersed with a fair bit of calculations. I'm guessing this is close to the ideal workload, as far as non-synthetic benchmarks go.
Re: New x86 micro-op vulnerability breaks all known Spectre defenses
#120I'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 think that cloud providers get dedicated SKUs. I can imagine if you give each VM dedicated cores and you can partition L3 cache per user, you could mitigate most of those issues.