1. TechSpot is dedicated to computer enthusiasts and power users. Ask a question and give support. Join the community here.
    TechSpot is dedicated to computer enthusiasts and power users.
    Ask a question and give support.
    Join the community here, it only takes a minute.
    Dismiss Notice

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

By onetheycallEric ยท 20 replies
Feb 17, 2019
Post New Reply
  1. 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.

  2. psycros

    psycros TS Evangelist Posts: 2,620   +2,353

    How about completely separate chips for the OS and applications? Didn't SPARC have this option?
    Danny101 likes this.
  3. xxLCxx

    xxLCxx Banned Posts: 226   +149

    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.
    Darth Shiv likes this.
  4. Darth Shiv

    Darth Shiv TS Evangelist Posts: 1,952   +575

    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: Feb 17, 2019
    xxLCxx likes this.
  5. Darth Shiv

    Darth Shiv TS Evangelist Posts: 1,952   +575


    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).
  6. Vulcanproject

    Vulcanproject TS Evangelist Posts: 695   +949

    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.
    jobeard likes this.
  7. Danny101

    Danny101 TS Guru Posts: 714   +266

    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.
  8. xxLCxx

    xxLCxx Banned Posts: 226   +149

    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). ;-)
    jobeard, Danny101 and HardReset like this.
  9. gamerk2

    gamerk2 TS Addict Posts: 218   +146

  10. gamerk2

    gamerk2 TS Addict Posts: 218   +146

    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.
    Danny101, HardReset and xxLCxx like this.
  11. Danny101

    Danny101 TS Guru Posts: 714   +266

    So what can be done? A hardware re-design doesn't seem realistic at this stage.
  12. Danny101

    Danny101 TS Guru Posts: 714   +266

  13. xxLCxx

    xxLCxx Banned Posts: 226   +149

    Either that or you run, head first, against the wall. ;-)
  14. Danny101

    Danny101 TS Guru Posts: 714   +266

  15. quadibloc

    quadibloc TS Enthusiast Posts: 46   +20

    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.
  16. STbob

    STbob TS Enthusiast Posts: 35   +14

    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.
  17. Darth Shiv

    Darth Shiv TS Evangelist Posts: 1,952   +575

    You are welcome to leave the conversation.
    Danny101 likes this.
  18. Danny101

    Danny101 TS Guru Posts: 714   +266

    Sure, you're probably right, but that sentiment hasn't stop people from talking about obvious things such as the weather.
  19. quadibloc

    quadibloc TS Enthusiast Posts: 46   +20

    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.
    onetheycallEric likes this.
  20. STbob

    STbob TS Enthusiast Posts: 35   +14

    Oh someone woke up on the wrong side of the bed. If you can't take the truth get out of the kitchen :)
  21. Danny101

    Danny101 TS Guru Posts: 714   +266

    You're just making the same circular point.
    Last edited: Feb 20, 2019

Add your comment to this article

You need to be a member to leave a comment. Join thousands of tech enthusiasts and participate.
TechSpot Account You may also...