11–20 of 24 posts
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.
Earlier quoted context omitted.
Right but didn't we already know that this hypothetical attack class exists? The possibility of remote spectre exploits like this was discussed in the original spectre paper. 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!)
Other than the AVX side channel, the interesting thing is that it demonstrates that the remote aspect definitely works. Before, it was theorized but might have proven to never give sufficient signal. While many were confident, now we know. 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…
The paper seems to say that they attacked a victim program that was specifically written to include vulnerable gadgets. 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?
Spectre just became a much bigger problem.
The AVX side channel is neat. It relies on power management rather than cache: after 1ms of AVX2 inactivity (no 256 bit operations being performed), it goes into a power-saving mode; the next 256-bit operation pays a ~2x cycle penalty. They get 8B/min at low error rate with AVX2. 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 b…
This one is going to be much more difficult to defeat. I suspect we will see more dangerous local exploits based on power side channels. 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 do…
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.
Earlier quoted context omitted.
Right but didn't we already know that this hypothetical attack class exists? The possibility of remote spectre exploits like this was discussed in the original spectre paper. 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!)
Other than the AVX side channel, the interesting thing is that it demonstrates that the remote aspect definitely works. Before, it was theorized but might have proven to never give sufficient signal. While many were confident, now we know. 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…
Until someone improves on this work.
This can pretty much all be laid at the feet of overly complex CPU designs and instruction sets. Looks like complexity is as evil for security in hardware as it is in software. 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.
This can pretty much all be laid at the feet of overly complex CPU designs and instruction sets. Looks like complexity is as evil for security in hardware as it is in software. 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.
> overly complex 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 sensiti…
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.
This can pretty much all be laid at the feet of overly complex CPU designs and instruction sets. Looks like complexity is as evil for security in hardware as it is in software. 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.
> overly complex 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 sensiti…
I'm wondering these days if Intel was onto something with EPIC/Itanium and just failed in the execution.