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: 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.