Stories
Slash Boxes
Comments

SoylentNews is people

CPU Security Mitigations

posted by chromas on Monday September 03 2018, @12:02AM   Printer-friendly
from the hackers-may-violate-your-ring dept.

An Anonymous Coward writes:

Intel has backtracked on the license for its latest microcode update that mitigates security vulnerabilities in its processors – after the previous wording outlawed public benchmarking of the chips.

With the Linux 4.19 kernel that just kicked off development this month has been continued churn in the Spectre/Meltdown space, just not for x86_64 but also for POWER/s390/ARM where applicable. For getting an overall look at the performance impact of these mitigation techniques I tested three Intel Xeon systems and two AMD EPYC systems as well as a virtual machine on each side for seeing how the default Linux 4.19 kernel performance -- with relevant mitigations applied -- to that of an unmitigated kernel.

At the BlackHat conference last month, Christopher Domas demonstrated an attack against an x86 CPU using MSR's and an embedded RISC core to bypass ring protections. The full presentation "GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUs" is viewable on YouTube. Is it time for CPU vendors to rethink security?

Original Submission

 
This discussion has been archived. No new comments can be posted.
CPU Security Mitigations | Log In/Create an Account | Top | 26 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by darkfeline on Monday September 03 2018, @09:38AM (5 children)

    by darkfeline (1030) on Monday September 03 2018, @09:38AM (#729806) Homepage

    Don't kid yourself, there's only one possible solution: only run trusted code, if you must, run untrusted code on isolated hardware.

    Places with real security demands (properly managed certificate authorities, top secret systems) already knew this for decades.

    There will always be security issues. So long as you only run trusted code and only expose a very restricted protocol externally (e.g., SSH), you only have to secure the limited API you expose, not the entire fucking CPU/OS.

    --
    Join the SDF Public Access UNIX System today!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by FatPhil on Monday September 03 2018, @09:47AM (2 children)

    by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Monday September 03 2018, @09:47AM (#729807) Homepage
    unless you're fabbing your own processors, you're running untrusted code anyway, that's part of the point of the article - your processors are coming with lots of bundled misfeatures.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves

    • (Score: 2) by darkfeline on Monday September 03 2018, @10:19PM (1 child)

      by darkfeline (1030) on Monday September 03 2018, @10:19PM (#729985) Homepage

      If you don't trust the processor, then worrying about malicious code taking advantage of processor design flaws is a non-issue. Fix the first issue before worrying about the second, i.e. make sure you can trust your processor before worrying whether it has unintended security issues.

      --
      Join the SDF Public Access UNIX System today!

      • (Score: 2) by FatPhil on Wednesday September 05 2018, @10:46AM

        by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Wednesday September 05 2018, @10:46AM (#730678) Homepage
        I don't know if we're in violent disagreement or not, but it comes over as if you've not WTFV. "make sure you can trust your processor before worrying whether it has unintended security issues" is also kinda meaningless - you can't trust your processor until you've verified it has no security issues, like an additional core that can execute code that violates the main processor's protection mechanisms.
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves

  • (Score: 0) by Anonymous Coward on Monday September 03 2018, @09:51AM

    by Anonymous Coward on Monday September 03 2018, @09:51AM (#729809)

    Don't kid yourself, there's only one possible solution: only run trusted code, if you must, run untrusted code on isolated hardware.

    Then you better eliminate the human factor, because those meatbags are the runners of untrusted code.

  • (Score: 0) by Anonymous Coward on Monday September 03 2018, @10:06AM

    by Anonymous Coward on Monday September 03 2018, @10:06AM (#729813)

    Don't kid yourself, there's only one possible solution: only run trusted code, if you must, run untrusted code on isolated hardware.

    Not practical. I disable javascript in my primary browser. I have to have it enabled on my secondary browser for an ever increasing number of sites, including my domain name registrar and DNS companies. Gone are the days when it was realistic to manually audit javascript, now we have massive js frameworks and Web Assembly.

    only expose a very restricted protocol externally (e.g., SSH), you only have to secure the limited API you expose, not the entire fucking CPU/OS.

    And of course, every single device that gets a shell via SSH? Unless you're prepared to run separate air gapped networks, it's not feasible.