Announcement

Collapse
No announcement yet.

Spectre V2 "Lite" App-To-App Protection Mode Readying For The Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spectre V2 "Lite" App-To-App Protection Mode Readying For The Linux Kernel

    Phoronix: Spectre V2 "Lite" App-To-App Protection Mode Readying For The Linux Kernel

    We are approaching one year since the Spectre and Meltdown CPU vulnerabilities shocked the industry, and while no new CPU speculative execution vulnerabilities have been made public recently, the Linux kernel developers continue improving upon the Spectre/Meltdown software-based mitigation techniques for helping to offset incurred performance costs with current generation hardware...

    http://www.phoronix.com/scan.php?pag...-App-To-App-V3

  • #2
    I want to ask. Why is it not possible to fix Spectre without performance hits?

    Why hasn't anyone thought of rather than predicting a branch, just pre-compute BOTH results of the branch? This may require more space in the die, but it will fix the problem.

    (I may be wrong)

    Comment


    • #3
      Originally posted by tildearrow View Post
      I want to ask. Why is it not possible to fix Spectre without performance hits?

      Why hasn't anyone thought of rather than predicting a branch, just pre-compute BOTH results of the branch? This may require more space in the die, but it will fix the problem.

      (I may be wrong)
      It's not practical because in the 100-or-so instructions being speculated, the cpu could easily need to speculate over many branches, assuming a lower count of 8, you would need 2^8 = 256 times as many resources, and that's just not practical.

      Comment


      • #4
        Originally posted by tildearrow View Post
        I want to ask. Why is it not possible to fix Spectre without performance hits?

        Why hasn't anyone thought of rather than predicting a branch, just pre-compute BOTH results of the branch? This may require more space in the die, but it will fix the problem.

        (I may be wrong)
        For those understanding Czech language there are videos
        https://www.youtube.com/watch?v=rwbs...ature=youtu.be
        and part two
        https://www.youtube.com/watch?v=cZiBJBuDvRw

        and
        https://www.youtube.com/watch?v=mIKSXv0Cgjg

        And there everything about two parts

        1. Speculation /prediction that rises up CPU performance
        2. Reading data that CPU may to forget/destroy but do not do so when mispressicted

        Once attacking program forces to miss-predict branch in victim program then data from speculation are not destroyed and can be read

        in mitigations:
        In each case when attacker is able to influence victim you need to flush data from cache that slows down CPU at about 100 times for small amount of time (since filling cache) or influence prediction that may slow down CPU 19 to 22 times for small amount of time.

        Slow downs depends on how often you need to do mitigations for your set of applications and CPU (not all CPUs contains all bugs)
        Last edited by Peter Fodrek; 10-18-2018, 03:16 AM.

        Comment


        • #5
          Originally posted by tildearrow View Post
          I want to ask. Why is it not possible to fix Spectre without performance hits?

          Why hasn't anyone thought of rather than predicting a branch, just pre-compute BOTH results of the branch? This may require more space in the die, but it will fix the problem.

          (I may be wrong)
          Even if it was practical, speculating both is even worse for security. You don't even need to "train" the predictor anymore.

          These performance hits happen because, effectively, these patches turn speculative execution off in certain contexts.

          So, if you never had speculative execution in the first place, you would have these "performance hits" all the time. They aren't actually hits, it's more like "how slow would the CPU be without speculative execution", that's basically what happens with these patches. But of course, only in certain cases, turning it off completely would be way slower.

          You've been enjoying all this performance precisely BECAUSE of speculative execution.

          Comment


          • #6
            Trying not to troll too much, but every time I see this kind of post it reminds me of something Terry Davis from TempleOS fame said... basically that Linux is designed to be a Unix clone that is itself designed for being a server platform. Because of this. Linux et al, have to inhibit the performance for single user desktop mode in order to accommodate the simultaneous multi-user server design, and all of the security precautions it must take. I wonder to what extent that holds true. As with the OpenBSD post that talked about disabling SMT for security reasons... I wonder what effect a desktop designed operating system would have on performance.

            Comment


            • #7
              Originally posted by tildearrow View Post
              I want to ask. Why is it not possible to fix Spectre without performance hits?

              Why hasn't anyone thought of rather than predicting a branch, just pre-compute BOTH results of the branch? This may require more space in the die, but it will fix the problem.

              (I may be wrong)
              Believe it or not that was actually one of the main selling points of the Itanium IA64 architecture.... But we all know how poorly it handled general purpose compute and how bad it handled x86 emulation because that feature.

              Comment

              Working...
              X