Hi,
I use Fedora Rawhide and noted that between commits 14f9643dc90a and
13b937206866 the gaming performance of my computer decreased in two
times.
I start bisecting and bisect blame this commit
138bcddb86d8a4f842e4ed6f0585abc9b1a764ff.
commit 233d6f68b98d480a7c42ebe78c38f79d44741ca9
Author: Borislav Petkov (AMD) <[email protected]>
Date: Thu Jul 6 15:04:35 2023 +0200
x86/srso: Add IBPB
Add the option to mitigate using IBPB on a kernel entry. Pull in the
Retbleed alternative so that the IBPB call from there can be used. Also,
if Retbleed mitigation is done using IBPB, the same mitigation can and
must be used here.
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
arch/x86/include/asm/nospec-branch.h | 2 +-
arch/x86/kernel/cpu/bugs.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+), 1 deletion(-)
I understand the concern about security but having 60FPS instead of
120FPS is not that I expected.
Unfortunately I couldn't just revert commit
233d6f68b98d480a7c42ebe78c38f79d44741ca9 because of conflicts.
But reverting all these commits:
❯ git revert 43972cf2deb2f54a97530c82b88c555fd682428e -n -m 1
❯ git revert 272b86ba9d97518b3c14b97514b6544eef87e7a5 -n -m 1
Auto-merging arch/x86/include/asm/processor.h
❯ git revert 77245f1c3c6495521f6a3af082696ee2f8ce3921 -n
Auto-merging arch/x86/include/asm/processor.h
❯ git revert 64094e7e3118aff4b0be8ff713c242303e139834 -n -m 1
❯ git revert 138bcddb86d8a4f842e4ed6f0585abc9b1a764ff -n -m 1
Auto-merging arch/x86/include/asm/processor.h
restore PC initial performance
My specs:
CPU: Ryzen 7950X
GPU: Radeon 7900XTX
Maybe it is possible to find another approach for solving security
issue without slowing down?
If not, then provide an option to turn off this slowdown.
I attached my build kernel config in the archive below.
--
Best Regards,
Mike Gavrilov.
On Sun, Aug 13, 2023 at 02:17:25PM +0500, Mikhail Gavrilov wrote:
> > spec_rstack_overflow=off
>
> Thanks, I checked this and it works!
Right, so you have Zen4 and it already uses the default mitigation and
no IBPB is mitigating retbleed because Zen4 is not affected. (If
retbleed mitigates with IBPB, that is also the SRSO mitigation but this
is not the case for your machine).
So yeah, I guess disabling the mitigation is one option.
Another could be if you supply:
spectre_v2_user=on spec_rstack_overflow=microcode
on the kernel command line after upgrading your microcode. That would at
least take care of protecting one user process from another.
There's no microcode for your machine yet, AFAICT, but you could still
try the above to see whether that mitigation type is better than no
mitigation at all wrt gameplay.
As to the microcode, I guess you'll get it with a BIOS update according
to:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html
the table cell about 7000 series.
HTH.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sun, Aug 13, 2023 at 1:24 PM Borislav Petkov <[email protected]> wrote:
>
> What do you have on your kernel command line?
log_buf_len=16M sysrq_always_enabled=1 nmi_watchdog=1
amdgpu.lockup_timeout=-1,-1,-1,-1 amdgpu.aspm=0
crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M
> What does
>
> grep -r . /sys/devices/system/cpu/vulnerabilities/
>
> say?
Attached as [vulnerabilities.txt]
>
> Please send a full dmesg, privately is fine too.
>
Attached as [dmesg.zip]
> If the bisection points to this patch, then it sounds like you have IBPB
> enabled as SRSO mitigation which is the heaviest one.
>
> The default one - safe RET - should be a lot better.
>
> > Maybe it is possible to find another approach for solving security
> > issue without slowing down?
>
> Yeah, magic. :-)
>
> > If not, then provide an option to turn off this slowdown.
>
> spec_rstack_overflow=off
Thanks, I checked this and it works!
--
Best Regards,
Mike Gavrilov.
On Sun, Aug 13, 2023 at 03:55:11AM +0500, Mikhail Gavrilov wrote:
> Hi,
> I use Fedora Rawhide and noted that between commits 14f9643dc90a and
> 13b937206866 the gaming performance of my computer decreased in two
> times.
> I start bisecting and bisect blame this commit
> 138bcddb86d8a4f842e4ed6f0585abc9b1a764ff.
What do you have on your kernel command line?
What does
grep -r . /sys/devices/system/cpu/vulnerabilities/
say?
Please send a full dmesg, privately is fine too.
If the bisection points to this patch, then it sounds like you have IBPB
enabled as SRSO mitigation which is the heaviest one.
The default one - safe RET - should be a lot better.
> Maybe it is possible to find another approach for solving security
> issue without slowing down?
Yeah, magic. :-)
> If not, then provide an option to turn off this slowdown.
spec_rstack_overflow=off
HTH.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sun, Aug 13, 2023 at 03:57:03PM +0500, Mikhail Gavrilov wrote:
> Sure, I checked and got the same results as on the kernel with reverted commits.
> I suppose when new BIOS update will release the kernel would use
> automatically path `spec_rstack_overflow=microcode` and all users who
> faced with this issue not needed add `spec_rstack_overflow=microcode`
> to their kernel command line, right?
No, you have to specify it explicitly. The default mitigation is still
safe RET.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sun, Aug 13, 2023 at 4:14 PM Borislav Petkov <[email protected]> wrote:
>
> No, you have to specify it explicitly. The default mitigation is still
> safe RET.
>
Too sad, this means that others must also face this problem. And not
everyone will know about a possible solution. Everyone will see that
the processor is simply running slower. Slower builds kernel, lower
FPS in games. And the slowdown is exactly two times. If there is
nothing to compare with, then everyone will think that it should be
there.
--
Best Regards,
Mike Gavrilov.
On Sun, Aug 13, 2023 at 04:38:59PM +0500, Mikhail Gavrilov wrote:
> Too sad, this means that others must also face this problem. And not
> everyone will know about a possible solution.
Nah, most people search the net and usually find the documentation, as
past experience shows. In this case, they will find:
https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html
It will be there next week but here's the source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/hw-vuln/srso.rst
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sun, Aug 13, 2023 at 7:19 PM Borislav Petkov <[email protected]> wrote:
> Nah, most people search the net and usually find the documentation, as
> past experience shows. In this case, they will find:
>
> https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html
>
> It will be there next week but here's the source:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/hw-vuln/srso.rst
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
I am figure out why I noticed lage impact of safe RET on my system.
safe-ret + KASAN = decrease performance for 50% in all scenarios
I use KASAN on a daily basis to catch bugs.
Is it possible for systems with KASAN to make a more optimal approach of SRSO?
--
Best Regards,
Mike Gavrilov.
On Mon, Aug 14, 2023 at 03:30:51AM +0500, Mikhail Gavrilov wrote:
> On Sun, Aug 13, 2023 at 7:19 PM Borislav Petkov <[email protected]> wrote:
> > Nah, most people search the net and usually find the documentation, as
> > past experience shows. In this case, they will find:
> >
> > https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html
> >
> > It will be there next week but here's the source:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/hw-vuln/srso.rst
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > https://people.kernel.org/tglx/notes-about-netiquette
>
> I am figure out why I noticed lage impact of safe RET on my system.
> safe-ret + KASAN = decrease performance for 50% in all scenarios
> I use KASAN on a daily basis to catch bugs.
> Is it possible for systems with KASAN to make a more optimal approach of SRSO?
Why do you care about speculation things on a dev box?