Bug 1201665

Summary:	kernel 5.3.18-150300.59.81-default is missing a kernel parameter for deactivation of the RetBleed mitigation on Intel Skylake CPUs
Product:	[openSUSE] openSUSE Distribution	Reporter:	Ralf Kölmel <ralf.koelmel>
Component:	Kernel	Assignee:	Borislav Petkov <bpetkov>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	duge, mhocko, suse, tiwai
Version:	Leap 15.3
Target Milestone:	---
Hardware:	x86-64
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Ralf Kölmel 2022-07-19 18:26:19 UTC

The kernel kernel 5.3.18-150300.59.81-default, which is mitigating the new Spectre variant RetBleed, is missing a kernel parameter which allows the single deactivation of this mitigation on Intel Skylake CPUs.
The deactivation, as mentioned in the kernel documentation, with retbleed=unret is only affecting AMD Epyc CPUs.
I've tried "retbleed=unret" or "retbleed=off" and i see always on lscpu "Vulnerability Retbleed:          Mitigation; IBRS"

Comment 1 Moritz Duge 2022-07-20 18:51:54 UTC

Maybe related: bug 1201664, bug 1201644 and bug 1201672

Try setting this boot parameter: spectre_v2=retpoline

If that's not working try: spectre_v2=off
But this may be bad regarding security of your system.

Comment 2 Borislav Petkov 2022-07-21 14:13:37 UTC

Yes, spectre_v2=off disables the retbleed mitigation on Intel. Retbleed cannot be disabled on most SLE kernels because the disable capability would've complicated the backport immensely and we wouldnt've managed to make in time.

And yes, it is not advisable to disable the retbleed mitigation.

Comment 3 Ralf Kölmel 2022-07-21 17:46:15 UTC

this (not to have a switch to disable only the RetBleed mitigation) is a big problem for our experiments with runtime comparisions to previous results.
Therefore disabling all Spectre v2 mitigations is no solution, too.
Is there some plan to backport this in the near future in Leap 15.X ?
(Will) Offer the Tumbleweed kernels or the next kernel from Leap 15.4 (the latest release kernel 5.14.21-150400.22-default hasn't the RetBleed mitigation) this possibility ?

Comment 4 Michal Hocko 2022-07-21 18:28:39 UTC

(In reply to Ralf Kölmel from comment #3)
> this (not to have a switch to disable only the RetBleed mitigation) is a big
> problem for our experiments with runtime comparisions to previous results.
> Therefore disabling all Spectre v2 mitigations is no solution, too.

I am not sure I understand. Could elaborate? What you are comparing here exactly?
Different kernel versions? Mitigations on vs off?

Comment 5 Ralf Kölmel 2022-07-21 18:47:24 UTC

(In reply to Michal Hocko from comment #4)
> (In reply to Ralf Kölmel from comment #3)
> > this (not to have a switch to disable only the RetBleed mitigation) is a big
> > problem for our experiments with runtime comparisions to previous results.
> > Therefore disabling all Spectre v2 mitigations is no solution, too.
> 
> I am not sure I understand. Could elaborate? What you are comparing here
> exactly?
> Different kernel versions? Mitigations on vs off?

in general we are researching algorithms in the field of theoretical informatics
but also with distinct practical usage e.g. in the route planning, energy informatics.
We are comparing runtime results during advancing our algorithms. 
It's clear that over the time kernel improvements and some advancement in compiler and libs have also an influence on our results.

In the past we have checked roughly (only with a small part of our algorithms), if a mitigation has some negative influence.

For now we can't check the isolated influence of RetBleed mitigation and 
there are not much data available from others about the influence of this RetBleed mitigation (between 14 and 39%).

Comment 6 Borislav Petkov 2022-07-21 22:03:35 UTC

(In reply to Ralf Kölmel from comment #5)

You can boot with mitigations=off and use that as the baseline for your measurements. The overhead of the return thunks which are part of retbleed is ~1% but that doesn't matter if you use this configuration as your baseline.

Comment 7 Ralf Kölmel 2022-07-21 23:09:12 UTC

(In reply to Borislav Petkov from comment #6)
> (In reply to Ralf Kölmel from comment #5)
> 
> You can boot with mitigations=off and use that as the baseline for your
> measurements. The overhead of the return thunks which are part of retbleed
> is ~1% but that doesn't matter if you use this configuration as your
> baseline.
It would be good to have such a baseline, but we haven't it yet and recomputations are time-consuming.

Comment 8 Michal Hocko 2022-07-22 07:43:59 UTC

(In reply to Ralf Kölmel from comment #7)
> (In reply to Borislav Petkov from comment #6)
> > (In reply to Ralf Kölmel from comment #5)
> > 
> > You can boot with mitigations=off and use that as the baseline for your
> > measurements. The overhead of the return thunks which are part of retbleed
> > is ~1% but that doesn't matter if you use this configuration as your
> > baseline.
> It would be good to have such a baseline, but we haven't it yet and
> recomputations are time-consuming.

This is really unfortunate but please consider that our top priority is to stabilize all the code streams. You can imagine that disruptive change like Retbleed mitigation is rather subtle and it can blow up easily. 

Saying that we might consider full retbleed disabling (including return thunks) later on but this is not the top priority at the moment.

Comment 9 Borislav Petkov 2022-08-01 12:07:49 UTC

Marking as WONTFIX currently.