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

  • #11
    Originally posted by timofonic View Post
    Vulnerabilities for everyone! When will CPUs be more debugged before commercial release and manufacturing?
    You're welcome to create a new spotless uArch! It's so easy to leave inane comments while having zero clue how complicated modern CPUs are. They are not TI calculators from the 80s.

    Comment


    • #12
      I wonder what happened to ConTExT - it was interesting read about how vulnerabilities can be fixed without huge performance loss.

      Comment


      • #13
        Originally posted by timofonic View Post
        Vulnerabilities for everyone! When will CPUs be more debugged before commercial release and manufacturing?
        Speculative execution problems were added to CPU in the Pent 2 that release date of May 7, 1997 then people correctly notice the problem with spectre 2017 is detected first and its only publicly released in 2018. Remember its gone to Intel first here(this will be important latter). Remember Pent 2 development starts over a year and half before the release date. So over 20 years to in fact notice we had a problem.

        Lets look at RetBleed effected cpus Zen 2 release date is 7 July 2019 there a problem that has out of the design stage and into production before spectre/meltdown fault comes know to AMD in great detail. Yes your gen 8 intel Oct. 5, 2017 so also into production before there is a known issue in the design by intel.

        Yes 2017-2019 time frame exposed a serous issue with lack of sharing of cpu security fault information with parties who really need to know. It was not only AMD but ARM and power and other CPUs that need to know about the core design fault that is the starting point for spectre and meltdown fault.

        This also exposed the lag with production how fast AMD and Intel can in fact change when a fault is found. Is the Zen 3/4 and Intel 9 and newer more debugged/checked for the kind of bugs that cause speculation faults in the design stage yes they are.

        The other problem is the cost of silicon production AMD and Intel in reality cannot afford to junk every bit of a mass produced chip. TSMC, Intel, samsung... foundries that make silicon chips need X income to function. The fact you order a stack of chips that don't work or have some fault in it does not mean you get to not pay the foundry.

        There is a horrible rock and hard place here. If fault is found before the silicon is mass produced then the design can be changed. If the fault is found after the chip as been mass produced vendors(amd, intel,samsung, apple...) will do everything to design a solution in software the reality here is if they don't the cost of paying for the foundries could possible put them out of business.

        There are horrible rough points for Intel and AMD when they had done a bad design that everyone knew before it went on sale and when customers did not by it really put them in a bad place. Foundry cost is not cheap. Recycling failed chips is also not cheap as well so you are talking cost of having the wafer made then extra cost to dispose of that defective wafer. This also explains why AMD and Intel are going after chiplet designs to get higher yield per wafer this results in more items to sell and less silicon recycling cost. Failure in silicon production is punished hard.

        This is why the idea that vendor will do the faults intentionally also does not stack up. If for some reason parties notice something really bad and not buy a companies silicon so leave company holding the costs this will either badly damage the company or at worst put the company out of business.

        Comment


        • #14
          Originally posted by skeevy420 View Post

          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.
          I meant stuff from the cmdline flag to enable that new mitigation technique, retbleed=stuff.

          Comment


          • #15
            Originally posted by timofonic View Post
            Vulnerabilities for everyone! When will CPUs be more debugged before commercial release and manufacturing?
            IIRC, more recent CPUs already contain fast IBRS in hardware. That's also why they aren't affected by Retbleed at all.

            Comment


            • #16
              Headline in two years: "RSB stuffing bypass by bad speculation (RSB-BS) vulnerability found in call depth tracking". And you know whose system will not be affected because they bit the bullet and turned IBRS on.

              Comment


              • #17
                "stuff" has a particular, appropriate, and historical meaning in Victorian English. Very amusing to see it used here for "retbleed=".
                Who says engineers do not have a sense of humor?

                Comment


                • #18
                  Originally posted by timofonic View Post
                  Vulnerabilities for everyone! When will CPUs be more debugged before commercial release and manufacturing?
                  Sigh. It's less to do with "debugging" a CPU and more to do with trying to think ahead or of other scenarios....WAY ahead of what might come down the pipe. CPU engineers are not idiots by and large. They're human. Humans make mistakes. As we've seen so clearly now, the past two decades of CPU engineers on the Intel (and, to a lesser degree, AMD) side cut corners to get performance at the expense of safety. It caught up with them in the past 4+ years since Spectre and all the other various attacks. As we are seeing, the exploit hunters keep hammering away and are finding still more cracks in the armor. For the most part, the CPU engineers have upped their game and can't cut those corners anymore in recent CPU designs. They can't possible think of every scenario because some clever person comes along and thinks way outside the box or develops some new exploit hunting / creation tool and finds this tiny little crack then iterates / engineers around it. Unless the feature that exploit hunters are targeting is removed wholly from the CPU, we'll be having this conversation years from now when xBLEED / Spectre v25 happens.

                  When car makers designed the first cars, did they plan for someone pouring sugar in a gas tank or stuffing a banana in the tail pipe to screw with the car? In 2022, you can STILL do that to 1/2 of all gas powered cars. The equivalent "mitigation" we've gotten for gas powered cars is that car makers (and gas station pump makers) FINALLY made the gas inlet hole small (and diesel pump tubes large) so morons who pick up the diesel fuel pump can't put it in and fill their gas car with diesel thus wrecking their engines. And yet, morons still find a way to pour diesel into their gas engines somehow. And thank god for the hose breakaway feature that detaches when...well, does it have to be further explained? We're humans, get used to it. It would be a slow news day without us.
                  Last edited by kozman; 17 July 2022, 12:22 PM.

                  Comment


                  • #19
                    Originally posted by cynic View Post
                    "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
                    With Spectre, sure, but Retbleed also hits AMD Zen 2 pretty bad, so it's not like AMD is doing any better here. I have Zen 2, but mitigations turned off, so it won't affect me, though.

                    But I forgot that AMD is never to blame as they are so perfect as viewed by pretty much everyone in tech communities.

                    Comment


                    • #20
                      Originally posted by Vistaus View Post
                      With Spectre, sure, but Retbleed also hits AMD Zen 2 pretty bad, so it's not like AMD is doing any better here. I have Zen 2, but mitigations turned off, so it won't affect me, though.

                      But I forgot that AMD is never to blame as they are so perfect as viewed by pretty much everyone in tech communities.
                      Mitigation turned off means you have the defect. So might cause you a few extra crashes/stability issues. These faults are not just security.

                      With the information sharing problem about design faults that effects AMD and Intel. AMD was not sharing its meltdown information clearly and Intel was not sharing the spectre information clearly. You can see this publicly in the early days of the Linux kernel mailing attempting to fix these faults. Yes having AMD or Intel developers saying X solution does not work then not giving details why.

                      2017-2019 shows a stack of system issues around silicon security problems. There was a big case of security by obscurity defect before 2017 by all silicon parties.

                      Things are better for silicon security than they use to be. But we cannot be sure everything is working right.

                      Comment

                      Working...
                      X