Unless modern CPU design changes significantly, side-channel attack vectors aren't going...

onetheycallEric

Posts: 225   +47
Staff
Big quote: "Computer systems have become massively complex in pursuit of the seemingly number-one goal of performance. We’ve been extraordinarily successful at making them faster and more powerful, but also more complicated, facilitated by our many ways of creating abstractions. The tower of abstractions has allowed us to gain confidence in our designs through separate reasoning and verification, separating hardware from software, and introducing security boundaries. But we see again that our abstractions leak, side-channels exist outside of our models, and now, down deep in the hardware where we were not supposed to see, there are vulnerabilities in the very chips we deployed the world over. Our models, our mental models, are wrong; we have been trading security for performance and complexity all along and didn’t know it."

In a recent white paper, researchers with Google security analyzed the continued prevalence and viability of side-channel vulnerabilities. Spectre and Meltdown gained notoriety last year, and fall into a class of attacks known as side-channel attacks -- specifically, side-channel attacks that prey upon CPU's speculative execution functionality.

The team behind the white paper was comprised of researchers and software engineers Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer, and Toon Verwaest. The team set out to explore the implications of side-channel attacks on security, software, and programming languages. While the paper is rife with details, evaluation was based on three primary topics: finding side-channels, understanding the speculative vulnerabilities, and mitigation. For each, the team built models and proof of concept.

Ultimately, they found that speculative vulnerabilities present a challenge that no software or code-based mitigation can truly address. The conclusion is that all processors that employ speculative execution will remain vulnerable at a hardware level, and the only magic bullet is a significant change in CPU design, leading to more secure hardware and the isolation of hardware and operating system processes. The research paper states that we need hardware and OS isolation now more than ever, which is why Google introduced Site Isolation with Chrome 66, and why Mozilla is planning to do the same with Project Fission.

What seems like the most obvious solution is to remove speculative execution, as the paper states. However, speculative execution is an important performance optimization technique used by most x86 processors, so CPU manufacturers would rather minimize vulnerabilities in other ways. Moreover, speculative execution is just too valuable to stop using. The paper outlines a few other possible mitigation techniques such as timer mitigation or branchless masking, but each come with caveats of their own, and there is no guarantee of their comprehensiveness.

The paper concludes that current CPU and architecture design are facing three unsolved problems: finding side-channel vulnerabilities, understanding them, and mitigating them in efficient and comprehensive ways. The paper ends with a statement, illuminating the security for performance trade-off CPUs have been making and suggesting that side-channel attack vectors will remain as long as CPU architecture remains unchanged.

"It is now a painful irony that today, defense requires even more complexity with software mitigations, most of which we know to be incomplete. And complexity makes these three open problems all that much harder. Spectre is perhaps, too appropriately named, as it seems destined to haunt us for a long time."

Permalink to story.

 
Error in headline: "Unless modern CPU design changes significantly, side-channel attack vectors aren't going anywhere".
Those attacks CANNOT be mitigated without a different hardware approach.
 
How about completely separate chips for the OS and applications? Didn't SPARC have this option?
That's not going to solve the issue. Many of the programs being exploited are user programs. How are you going to determine which needs to go where?

Ps you can already set processor affinity. Maybe we as a workaround can just put processes we want to isolate on one set of cores and the user exposed ones on another set? So as long as you can answer the question in the previous paragraph, you could do your approach already with affinity.
 
Last edited:
Error in headline: "Unless modern CPU design changes significantly, side-channel attack vectors aren't going anywhere".
Those attacks CANNOT be mitigated without a different hardware approach.
Exactly.

My thinking is they really need to have a secure check instruction that NEVER runs speculative execution. You would then need to amend programming language compilers to support the new instruction and therefore the higher level languages will need programming constructs to use those new instructions.

That way for non-sensitive code, you keep your performance of speculative execution and for security, you have the control you need over the CPU to address this issue. You could then amend the binaries for vulnerable programs to change the instruction (check for availability of the new instruction and use it etc).
 
The very nature of increasing complexity.

The more complex a given system becomes, the more vulnerable it is. You can apply this to a raft of known systems besides computing. Our civilization, for one.
 
More modularity is needed. Just like multiple programs began running in protected mode in Windows to isolate programs that misbehave. With multiple cores, why can't Windows isolate to specific cores instead? The majority of programs don't take advantage of multi-cores anyway. Each core will have it's own allocated memory space as well. Surely, Windows can be programmed to work that way without restructuring the hardware.
 
More modularity is needed. Just like multiple programs began running in protected mode in Windows to isolate programs that misbehave. With multiple cores, why can't Windows isolate to specific cores instead? The majority of programs don't take advantage of multi-cores anyway. Each core will have it's own allocated memory space as well. Surely, Windows can be programmed to work that way without restructuring the hardware.
It turns out, the Isolation doesn't work. Not even with a single core. Speculative execution simply ignores much of it. Programs call system routines and libraries. You'd have to clear the caches all the time. The performance impact would be devastating, rendering the whole speculative execution superfluous (which would probably be the honest thing to do). Keep in mind that modern processors can perform thousands of instructions while waiting for a single memory access (RAM). Now, subtract the cache and see where it gets you. In some BIOSes you can turn off 1st, 2nd, and 3rd level caches altogether. Back in the days, I accidentally turned off the second level and barely managed to boot (it took ages). ;-)
 
More modularity is needed. Just like multiple programs began running in protected mode in Windows to isolate programs that misbehave. With multiple cores, why can't Windows isolate to specific cores instead? The majority of programs don't take advantage of multi-cores anyway. Each core will have it's own allocated memory space as well. Surely, Windows can be programmed to work that way without restructuring the hardware.

This would tank performance by at least 60-70%, probably more. Speculative execution isn't just a "performance hack", it can easily account for a 30-40% performance boost across the board.

Secondly, threads jump between cores all the time; Windows allocates the highest priority thread(s) at any moment in time, and there's no way to predict what core thread(s) are running on at any specific point in time.

Finally, if every core had it's own address space, then every time a thread gets bumped data would need to be copied from main memory (as it's unlikely a thread would have it's data in that CPU cores cache when it gets assigned), which would farther cost performance.

The fact is, we made software so secure it's now easier to attack the hardware itself.
 
How about completely separate chips for the OS and applications? Didn't SPARC have this option?
That's not going to solve the issue. Many of the programs being exploited are user programs. How are you going to determine which needs to go where?
That is a good point. But if speculative execution is too valuable to get rid of, and yet only by getting rid of speculative execution can a processor be secure, then using speculative execution only for trusted application programs that need performance seems like not only the obvious solution, but the only solution.
Although processor affinity, as you also noted, might work as well, with changes to operating systems to make it easier to use and to provide a secure default: the OS has one processor, untrusted Internet programs have another, and trusted applications needing performance use the rest.
 
How about completely separate chips for the OS and applications? Didn't SPARC have this option?
Lots of armchair quarterbacks making suggestions. The engineers are just a few steps ahead of you all on this. None of your comments will make it to R&D of cpu companies so save your typing it won't matter in the grand scheme of things.
 
Lots of armchair quarterbacks making suggestions. The engineers are just a few steps ahead of you all on this. None of your comments will make it to R&D of cpu companies so save your typing it won't matter in the grand scheme of things.
You are welcome to leave the conversation.
 
Lots of armchair quarterbacks making suggestions. The engineers are just a few steps ahead of you all on this. None of your comments will make it to R&D of cpu companies so save your typing it won't matter in the grand scheme of things.
Sure, you're probably right, but that sentiment hasn't stop people from talking about obvious things such as the weather.
 
Lots of armchair quarterbacks making suggestions. The engineers are just a few steps ahead of you all on this.

I should hope so. However, this article disclosed something that was new - new even to those engineers, that while there are mitigations for Spectre and Meltdown, weaknesses like them are so ingrained in speculation that new ones will always be found.

Given that, it makes sense that the obvious responses to such a situation will be discussed here. And I think the engineers will have thought of them too, and also other better responses.
 
Back