>"Intel's suggested defense against Spectre, which is called LFENCE, places sensitive code in a waiting area until the security checks are executed, and only then is the sensitive code allowed to execute," Venkat said. "But it turns out the walls of this waiting area have ears, which our attack exploits. We show how an attacker can smuggle secrets through the micro-op cache by using it as a covert channel." >"In the…
The best part of the new "defense against Spectre" is that the LFENCE instruction has been around for ~20 years. It's not even not a defense against all variants.
lfence behavior varies. On AMD CPUs you need to set an MSR to make it serialize instruction dispatch.
> 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…
turing architecture - code and data are handled the same way. harvard architecture - code and data are separate things
There are separate micro op caches per core however they are typically shared among hyperthreads. I wonder if this could be another good reason for cloud vendors to move away from 1vCPU = 1 hyperthread to 1vCPU = 1 core for x86 when sharing machines (not that there weren't enough good reasons already).
Cloud vendors probably use a hypervisor that schedules the VM time slices in a way that hyperthread siblings are only ever cooccupied by the same guest.
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…
>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.
I don't see how "average users don't do high-security tasks" somehow helps the argument that "high-security tasks are rarely high-intensity tasks".
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…
> We're going to wind up undoing the last 20 years of performance gains in the name of 'security', and it scares me. This actually excites me. When the foundation is shown to be rotten, it's time for a new foundation. I'm optimistic, though, that the future holds a fork, with some devices insecure-but-fast and others secure-but-slow. Because there's a market for both. I don't care if my gaming hardware is vulnerable…
I have a feeling that the wide spectrum of different ways to mitigate CPU bugs will slow down the demand for a new "slow and steady" CPU architecture. Linux already comes with a feature to wipe the L1 cache on every context switch -- simply enabling this option will compete with brand new architectures for a while.
A major advantage of not adopting new CPU designs for a while is that you get to keep insecure-but-fast and secure-but-slow behavior in the same CPU by simply tweaking mitigations.
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…
I posit something even simpler. JavaScript bloat exists because it's easy to learn and put something real on a screen for a newb, and it's a pleasure to write in. Writing these frameworks/libraries/websites/whatevers is literally its own reward, and the barrier to sharing tools is low. That, coupled with enthusiastic developers across the entire spectrum of niavete and experience finding new tools fun and exciting to develop and use, and you have an ecosystem with endemic bitrot. It feels absurd to have to say this, but the people who are a part of this ecosystem and contribute to the bloat do not despise the ecosystem the way HN people seem to. They don't see it as broken. It's not going away.
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…
20 years ago, computer magazines wrote about single-core 10GHz CPUs. Billions of transistors. What we have can barely be described as performance gains more than "add SIMD and more cores, and performance hacks".
As opposed to the billion transistors we have now?
>"Intel's suggested defense against Spectre, which is called LFENCE, places sensitive code in a waiting area until the security checks are executed, and only then is the sensitive code allowed to execute," Venkat said. "But it turns out the walls of this waiting area have ears, which our attack exploits. We show how an attacker can smuggle secrets through the micro-op cache by using it as a covert channel." >"In the…
The best part of the new "defense against Spectre" is that the LFENCE instruction has been around for ~20 years. It's not even not a defense against all variants.
So what? The defense relies on it serializing the instruction stream which is not necessarily true based on the semantics of the instruction (until it was retroactively documented to do so)
The first known Spectre-like concept was actually traced to Pentium 3 times in nineties. It took 2 decades for everybody to forget about it before the vulnerability dismissed as "not exploitable in the practice" came back with a vengeance.
I'd really appreciate a link to this, sounds really interesting.
It's on Wikipedia (away from pc) on the meltdown article