Announcement

Collapse
No announcement yet.

Retbleed: Call Depth Tracking Mitigation Eyed To Avoid IBRS "Performance Horror Show"

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

  • Retbleed: Call Depth Tracking Mitigation Eyed To Avoid IBRS "Performance Horror Show"

    Phoronix: Retbleed: Call Depth Tracking Mitigation Eyed To Avoid IBRS "Performance Horror Show"

    Due to the new "Retbleed" security mitigation further hurting CPU performance for affected processors, Intel engineers have revisited work on call depth tracking mitigation as an alternative to the Indirect Branch Restricted Speculation (IBRS) mitigation to help in lowering the overhead costs...

    https://www.phoronix.com/scan.php?pa...Depth-Tracking

  • #2
    Michael I would love to see some tests on what the performance impact is on the various mitigations being compiled into the kernel even if they aren't used. Given that the email in this news item talked about that I'm worried, as I'm on Zen 3 and don't want the impact from unnecessary mitigations. Am I going to need to compile my own kernels in the future?

    Comment


    • #3
      > While CPUs are good in ignoring NOPs they still pollute the I-cache.

      Well, I for one, welcome out new nop2 nop4, nop8, nop16...nopN instructions and would like to remind Intel that, as a trusted forum member, I can be helpful in rounding up others in praise of their glorious architectural designs.

      Comment


      • #4
        Originally posted by Vorpal View Post
        Michael I would love to see some tests on what the performance impact is on the various mitigations being compiled into the kernel even if they aren't used. Given that the email in this news item talked about that I'm worried, as I'm on Zen 3 and don't want the impact from unnecessary mitigations. Am I going to need to compile my own kernels in the future?
        But WAIT, There's MORE

        1) Text size increase which is inflicted on everyone. While CPUs are good in ignoring NOPs they still pollute the I-cache.

        2) That results in tail call over-accounting which can be exploited.
        Since you can't be exploited we'll make an exploit based on the mitigation that mitigates those who are exploited.

        Damned if they do, not damned if they don't.

        Comment


        • #5
          Does stuff stand for anything or couldn't the devs just not come up with a better name?

          Comment


          • #6
            Originally posted by Jbk0 View Post
            Does stuff stand for anything or couldn't the devs just not come up with a better name?
            Which one? The one that looks like Irritable Bowel Syndrome or the one that's the combination of Retpolines and, I guess, Heartbleed or OptionsBleed.

            Comment


            • #7
              Weirdly Windows does not incur this huge performance loss as it already contains mitigations against this vulnerability. I've no idea why and how.

              Comment


              • #8
                Originally posted by birdie View Post
                Weirdly Windows does not incur this huge performance loss as it already contains mitigations against this vulnerability. I've no idea why and how.
                So Windows makes use of IBRS by default, right?

                If so, this should provide Linux with a performance edge, here.

                Comment


                • #9
                  "Back in the good old spectre v2 days (2018)"

                  it's nice to see that Intel engineers are having fun patching their employer expensive CPU while our workstations get slower and slower day after day

                  Comment


                  • #10
                    Vulnerabilities for everyone! When will CPUs be more debugged before commercial release and manufacturing?

                    Comment

                    Working...
                    X