In Google Cloud, from unrelated instances, they're getting 1 byte every 8 hours (3 if the target has an AVX2 gadget). Attacks tend to get better over time, but still, that's an AES key in a few days, and it assumes one discrete target; in a real deployment, that secret might be mirrored over hundreds of instances.
Like I said, I don't know the specifics, but there are methods of doing better than guessing.
Mitigating those will be bad for power usage and performance. We can imagine future processors will manage cache state differently, keeping all changes local to the core until the relevant instructions retire. I have no idea how you would mitigate functional unit power up / power down without destroying the usefulness of the feature itself.
Or at least execute it on the slow path if the unit is not up (lower execution width) without triggering the ramp-up as long as it is speculative. Only ramp-up when the instruction is committed.
Is code for this victim program available? I don't see it in the paper.
Have such gadgets been found in any real-world programs?
It's certainly interesting to construct an example and show it working, but this isn't surprising, is it?
Just trying to understand if I've missed something here.
(The AVX side channel is certainly new and interesting, though!)
Further, it shows how to do it (classifier) and gives a very good model for what bandwidth can be expected in practice. And still further, that bandwidth is entirely sufficient for attacking long lived cryptographic key material. Before, it was easy to theorize that the bandwidth would simply be too low. Now it isn't.
This is also really good because the bandwidth is really low. For data larger than a key (or where you would need to scan a lot to find the data), we can be much more comfortable with infeasibility arguments by basing them on some security margin beyond these experiments. As an example, if it would take 1 <timeunit> to exfiltrate a single credit card number even if the technique got 10 times better, maybe that means it isn't a sufficient risk. Or maybe it is. (All depends on the time unit and the risk.) But now we can make that assessment with a real baseline instead of a guess.
Until someone improves on this work.
On the plus side part of why you see more of these kinds of attacks is that we have actually made progress on software security.
Speculative execution is what makes our sequential code fast by exploiting parallel execution pipelines that would otherwise sit idle.
Avoiding this would increase complexity somewhere else, e.g. compilers would have to become even more clever or programmers would have to work harder to reduce the branches in their code. Sprinkling code with annotations to prevent speculative execution around sensitive data is of course just another way complexity does go up to let us keep the performance gains of speculation.
Not really. Compilers are already stupendously complicated since they inherit a ton of techniques used for older processors that required, e.g. instruction scheduling and other tricks. CPUs getting bigger and faster just added additional complexity to extract even more dynamic parallelism and also do the job of simpler compilers.
It's much easier to turn off the complexity in a compiler and reason about the resulting program. The complexity in the CPU cannot be switched off and is closed source.
Gimme simple CPUs again.
I'm wondering these days if Intel was onto something with EPIC/Itanium and just failed in the execution.
Itanium's slowness is generally very exaggerated (at least in part because the first Itanium had a rather slow memory subsystem, and the performance kind of sucked as a result). Circa 2008 or so the fastest database servers available were Itanium. Unfortunately, it emulated x86 extremely slowly and amd64 ran x86 very quickly, so AMD kinda ate Intel's lunch.
Does anyone know of a good writeup on the original vulnerability that's a little less technical? Like a lot of people on HN I came into programming via systems administration so I don't have a lot of low level knowledge.
this class of attack is theoretical, and all the hype is unsubstantiated. clearly y'all haven't read the paper. people never read past the headlines any more...
you don't even have to take my word for it, READ THE PAPER:
> As NetSpectre is a network-based attack, it cannot only be preventedby mitigating Spectre but also through countermeasures onthe network layer. A trivial NetSpectre attack can easily be detectedby a DDoS protection, as multiple thousand identical packets aresent from the same source. However, an attacker can choose anytrade-off between packets per second and leaked bits per second.Thus, the speed at which bits are leaked can simply be reducedbelow the threshold that the DDoS monitoring can detect. This istrue for any monitoring which tries to detect ongoing attacks, e.g., intrusion detection systems. Although the attack is theoretically not prevented, at some point the attack becomes infeasible, as the time required to leak a bit increases drastically. Another method to mitigate NetSpectre is to add artificial noise to the network latency. As the number of measurements depends on the variance in network latency, additional noise requires an attacker to perform more measurements. Thus, if the variance in network latency is high enough, NetSpectre attacks become infeasible due to the large number of measurements required.