Disabling Spectre V2 Mitigations Is What Can Impair AMD Ryzen 7000 Series Performance

[F.Ultra]

Mitigating Spectre variant 2 with Retpoline on Windows - Microsoft Tech Community

Yeah I saw those (it's the same link that ll1025 provided, but what is puzzling is that lots of Windows sites started to report that the performance hit from Windows 10 disappeared with build 1809 and they cannot all have run pre-skylake cpu:s one would imagine. Then as of Cascade Lake, Intel added eIBRS, so this is basically just a Skylake problem (on the Intel side).

[hotaru]

The big question is that Windows really uses, they seem to have been used both retpolines and IBRS, but if they used IBRS already in 2018 then they must have taken a huge performance hit on the CPU:s without eIBRS, did no one cry over that or was/is it not enabled by default on all systems?

edit: ok so to make things more complex it looks like Microsoft went the same route as Linux in 2019 in that they replaced IBRS with retpolines in build 1809 of Windows 10. So I wonder if anyone have actually tried to run retbleed on Windows or if it's only assumed that it isn't vulnerable (on CPU:s without eIBRS).

Mitigating Spectre variant 2 with Retpoline on Windows - Microsoft Tech Community

Since Retpoline is a performance optimization for Spectre Variant 2, it requires that hardware and OS support for branch target injection to be present and enabled. Skylake and later generations of Intel processors are not compatible with Retpoline, so only Import Optimization will be enabled on these processors.

Retpoline is not applicable to Skylake and later processors from Intel.

[Anux]

Linus rejected it, in part for performance reasons

He didn't reject it because of performance his argument was that no one will probably use it because of the performance hit. At least that's how I understand it.

Although I also think that this shouldn't be of concern for the kernel devs. Just supply the most secure code possible and give people the chance to opt out.

[F.Ultra]

But the mitigation that defeats it-- IBRS-- was recommended by Intel in 2018 to both Microsoft and Linux, and patchsets were proposed. Torvalds rejected them partly because of performance. Microsoft implemented them, which is why Retbleed did not affect Windows (noted by Intel, among others).

I've provided links elsewhere in this thread, but googling the following should get you some sources:

• Windows IBRS retbleed
• Linux IBRS 2018 Torvalds

Thanks! Looking that the entire discussion three on the patch it seems like performance was not the only reason why it was rejected, Linus had many comments on the patch doing many weird stuff that was never mentioned in the initial post on how and what the patch was for and I can also note that Amazon never address them. Interestingly both Intel and AMD in the end (as of zen 3 and Cascade Lake(?)) did exactly what Torvalds told them to do here, which is to automatically call IBRS in the hardware when you switch to ring 0 (aka the eIBRS).

The big question is that Windows really uses, they seem to have been used both retpolines and IBRS, but if they used IBRS already in 2018 then they must have taken a huge performance hit on the CPU:s without eIBRS, did no one cry over that or was/is it not enabled by default on all systems?

edit: ok so to make things more complex it looks like Microsoft went the same route as Linux in 2019 in that they replaced IBRS with retpolines in build 1809 of Windows 10. So I wonder if anyone have actually tried to run retbleed on Windows or if it's only assumed that it isn't vulnerable (on CPU:s without eIBRS).

[ll1025]

My response with sources is en-route but requires approval because it has all of the sources.

I literally got them by googling the above phrases, checking the bleepingcomputer article and its link to the intel advisory, the lkml response by Torvalds, and Microsoft's own write-up on Spectre v2 Mitigations.

But since you want me to deliver them, you get to wait until my post is approved.

[ll1025]

Oh good grief, talk about lazy.

You said that multiple times but faild to prove it anywhere.
...
The only thing I found so far is Linus ranting about intel not fixing their CPU's and let the kernel dev's fix intels errors.

Intel provided the patchset. Linus rejected it, in part for performance reasons. See the bottom, to quote:

But since we already know that the IBRS overhead is <i>huge</i> on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high.

And yet here we are, adding IBRS to kernel 5.19 via commit 6ad0ad2bf8a6, when Windows added it years ago and was unaffected by retbleed because of it:

Our original mitigations for Spectre variant 2 made use of new capabilities exposed by CPU microcode updates to restrict indirect branch speculation when executing within kernel mode (IBRS and IBPB).

and

Windows operating system uses IBRS by default, so no update is required.

EDIT: Also interesting is discussion from others on IBRS, which boils down to whether a "theoretical issue" is worth patching. Linus and others seemed to have settled on no, despite Intel and AWS engineers making it clear that IBRS was still necessary.

[Anux]

Torvalds rejected them partly because of performance.

You said that multiple times but faild to prove it anywhere.

I've provided links elsewhere in this thread

No you didn't.

• Windows IBRS retbleed
• Linux IBRS 2018 Torvalds

The only thing I found so far is Linus ranting about intel not fixing their CPU's and let the kernel dev's fix intels errors.
And I'm totaly with this argument.

[ll1025]

Do you know and understand the ways spectre v2 is mitigated? I said *IBPB* which is distinct from both IBRS and retpoline. AMD chips don't even possess IBRS.

Funny, then, that AMD identified IBRS as one of two mitigations against Spectre v2 (CVE-2017-5715) in their technical guidance. (page 5, section 5, paragraph 2), and reference it as a feature supported by their processors (page 2, "Presence").

[ll1025]

Retbleed was first announced in 2022, did you mean some other patches? The only ones I can recall having criticism from Linus was the one from Amazon for the snoop vulnerability and that was criticism, he didn't reject it.

But the mitigation that defeats it-- IBRS-- was recommended by Intel in 2018 to both Microsoft and Linux, and patchsets were proposed. Torvalds rejected them partly because of performance. Microsoft implemented them, which is why Retbleed did not affect Windows (noted by Intel, among others).

I've provided links elsewhere in this thread, but googling the following should get you some sources:

• Windows IBRS retbleed
• Linux IBRS 2018 Torvalds

[F.Ultra]

Do you know and understand the ways spectre v2 is mitigated? I said *IBPB* which is distinct from both IBRS and retpoline. AMD chips don't even possess IBRS.

*IBPB* is issued during context switches to prevent past branches from affecting future predictions. That's it's entire purpose. [1]

In this test IBPB was enabled during the "mitigations enabled" scenario, though selectively applied, and completely disabled during the no-mitigations run.

[1] This is particularly important on windows, because they can't just recompile the world to use repolines on AMD hardware. People always use old versions of software and issuing IBPB on every context switch protects *all* applications regardless of whether they've been recompiled.

Zen 4 have IBRS, it's enabled automatically when you enter ring 0 and disabled once you exit. Spectre V2 can be exploited by another process running on a sibling processor so only doing mitigation when scheduling processes is not enough to mitigate it. Also Michael runs a single process for each benchmark so the number of context switched due to scheduling should be quite low (though he doesn't pin threads to cores so some scheduling does happen within the same process of course).

IBPB is used to protect from the scheduling issue as you write, but are there enough such cases in benchmarks of single processes at a time to create this type of overhead? Unsure if IBPB can be disabled while keeping the repolines/IBRS but if that is the case then it would be interesting to see a run of that to figure this out, because if AMD doesn't do a real barrier with IBPB then things can get real ugly here and it would be a strange path of them to take.

edit: I also fail to see how this would benefit them in mitigations=on vs off since this is benchmark runs, aka the entire machine only runs a single application so there would be no benefit from "oh this is a new application so lets do retraining" since it's the same application and also retraining from scratch is what every cpu have to do after IBPB anyway so I still fail to see how this could explain it.