|
Bugzilla – Full Text Bug Listing |
| 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
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. 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. 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 ? (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 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%). (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. (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. (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. Marking as WONTFIX currently. |