• 4 Posts
  • 421 Comments
Joined 1 year ago
cake
Cake day: February 16th, 2024

help-circle













  • Yeah… I mean, I did hedge by saying “depends on your CPU and your risk profile”, but I understand your point and will edit my comment to caution readers before playing with foot finding firearms.

    From my understanding it’s a mixed bag. Some of those vulnerabilities were little more than theoretical exploits from within high levels of trust, like this one. Important if you’re doing a PaaS/IaaS workload like AWS, GCP etc and you need to keep unknown workloads safe, and your hypervisor safe from unknown workloads.

    Others were super scary direct access to in-memory processes type vulnerabilities. On Linux you can disable certain mitigations while not disabling others, so in theory you could find your way to better performance at a near zero threat increase, but yes, better safe than sorry.



  • no performance change

    You must be new here.

    Joking. In reality it depends.

    The first iteration of this comment had a cheeky observation about the performance impact of these CPU mitigations on Linux, some of which have nearly no real world threat to people not running cloud providers.

    And while that’s true to a degree, tests disabling some or all of the most modern set of mitigations show that most have become highly optimized and the CPUs themselves have iterated over time to increase the performance of the mitigations as well.

    And many of these CPU vulnerabilities actually had in the wild use and can still do horrible things with very little surface exposure from your system. Apologies to the people who read the first version of this comment and took the time to rightly push back.