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

[stormcrow]

So Windows makes use of IBRS by default, right?

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

Yeah that's what the Linux kernel community thought with their current mitigations, yet IBRS is not vulnerable to Retbleed. The people that proposed reviving the alternative mitigations points out that even though the researchers couldn't break their mitigation, there's no scientific proof that it will hold up to other attacks. The only way to do that is a very long and laborious formal proof. The same may be true of IBRS as well. Far as I know, no one has carried out a formal verification of IBRS either.

The problem is that all of the optimizations are mere... speculation... that they will work without side effects. That's been proven to be untrue. What we need are scientifically rigorous approaches to optimization that can bear up under formal verification. We've literally outrun our ability to verify the integrity of our hardware and we're unfortunately reaping those consequences. Keep in mind this is a problem across all architectures that use this kind of optimization. It's not limited to Intel or AMD. ARM and POWER with speculative execution also suffer from these same problems. Processors without speculative execution may have other unforeseen problems as well. Just no one has bothered to go looking yet.

[Ironmask]

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

It reminds me of I Have No Mouth And I Must Scream when Gorrister explains what AM stands for;
"At first it meant Allied Mastercomputer, and then it meant Adaptive Manipulator, and later on it developed sentience and linked itself up and they called it an Aggressive Menace, but by then it was too late, and finally it called itself AM, emerging intelligence, and what it meant was I am … cogito ergo sum … I think, therefore I am."

[kozman]

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.

Yeah AMD is not blameless here either. This is what happens when designers copy-cat others' ideas: they copy-cat the flaws too. I used a lot of AMD in the 90s and 2000s but switched to Intel when it was obvious AMD just couldn't get their shit together. If you believe the conspiracy of Microsoft / Intel paying the industry to cripple or make sub part parts for AMD CPUs back then....well, I always saw it as the industry flocking to whoever made them the most money. AMD was not making them tons of money so their was, IMHO, DISinvestment for sure. I suppose, post-Spectre etc., a lot of AMD folks felt vindicated to learn why AMD CPU were always 2nd fiddle to Intel because Intel cut so many corners to outpace other CPUs. Ain't so much like that anymore. The playing field got leveled really quick the past 4+ years and only now are all CPU vendors on their toes and side-eyeing each other in the process. LOL.

[skeevy420]

I meant stuff from the cmdline flag to enable that new mitigation technique, retbleed=stuff.

Heh. I had a chuckle at that one, too. I thought you meant the names themselves.

[fahrenheit]

I meant stuff from the cmdline flag to enable that new mitigation technique, retbleed=stuff.

Stuff as in stuffing, i.e. put something in another thing to make it bigger, like turkey stuffing. In this case stuffing instructions onto the pipeline, the noop's referenced on the mailing list comment

[oiaohm]

Yeah AMD is not blameless here either. This is what happens when designers copy-cat others' ideas: they copy-cat the flaws too.

Copy-cat each other ideas then add security by obscurity on top leads to one huge mess. AMD and Intel.... all had using the same base research document on how todo speculative execution from early 1990s but they were not sharing due to security by obscurity methods they were not sharing the defects in the implementations with each other. The fact the base document had faults would have come out in the early 2000 if they were sharing minor design bugs with each other.

The reality is copying each other ideas does equal copying flaws but there is also the problem that if you are not sharing the issue you are hitting implementing the stuff you can basically end up with a obscurity problem preventing you from knowing that what you are implementing is totally broken.

You could say that AMD, Intel and other cpu designers for somewhere between 15 to 20 years basically designing CPU like driving a car while blind folded so its more luck than good management that we got 20 years of use out the CPU without everyone working out hey we have a major issue.

Security by obscurity can be really bad thing. Security by obscurity mixed with copy cat other ideas always leads to bad outcome sooner or latter.

[Developer12]

Gee, I wonder if this patchset takes into account returns in UEFI firmware calls or SMM or vBIOSs or other fun junk that could prematurely underflow the RSB?

[kozman]

Copy-cat each other ideas then add security by obscurity on top leads to one huge mess. AMD and Intel.... all had using the same base research document on how todo speculative execution from early 1990s but they were not sharing due to security by obscurity methods they were not sharing the defects in the implementations with each other. The fact the base document had faults would have come out in the early 2000 if they were sharing minor design bugs with each other.

The reality is copying each other ideas does equal copying flaws but there is also the problem that if you are not sharing the issue you are hitting implementing the stuff you can basically end up with a obscurity problem preventing you from knowing that what you are implementing is totally broken.

You could say that AMD, Intel and other cpu designers for somewhere between 15 to 20 years basically designing CPU like driving a car while blind folded so its more luck than good management that we got 20 years of use out the CPU without everyone working out hey we have a major issue.

Security by obscurity can be really bad thing. Security by obscurity mixed with copy cat other ideas always leads to bad outcome sooner or latter.

Security by obscurity rarely works as you say. Eventually, someone figures out the obscurity part and the security becomes a big mess created for all users. And yes, it's true, we're here because of the hyper-secrecy of the bugs known almost 2 decades ago. I get that industries protect their trade secrets but sometimes at what cost to consumers? If the intent was to kill a LOT of old hardware that was still working but has this major CPU flaw then they hit the nail on the head for sure.

Craig Barrett probably bears a lot of blame here. But I sure remember AMD's easygoing Jerry Sanders. The "Jerry Garcia" of semiconductors as I fondly remember him.

[kozman]

Gee, I wonder if this patchset takes into account returns in UEFI firmware calls or SMM or vBIOSs or other fun junk that could prematurely underflow the RSB?

Likely not. I think this is likely to be a quick and dirty patch to stop the proverbial bleeding and claw back some performance quick. 5.20 is likely to be the next LTS kernel and it's gonna suck hard if it's hobbled out of the gate I would think. It took how many years post-Spectre to sort of claw back all the perf lost to mitigation? With this new issue it's like being right back to square one in terms of a perf hit.

It's good to see Gleixner and Zijlstra proactively looking to attack the problem with their patches but I don't think they'll get pulled in so quick until having baked and been field tested for a bit. We'll see how much effort it's going to take to claw back all the lost perf. We'll have to stay tuned I guess.

[Mario Junior]

All my bois use mitigation=off.