Disable mitigations

I am fully updated:
5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux

I find no “mitigations” kernel parameter. Why not?

Thanks for reading.

As far as I know it is not possible to disable this with a kernelparameter you would need to build the kernel with this one disabled

Thank you for your reply. When I get time, I will look into the problem further. It would be very helpful if there were a quick way to shut these mitigations down for those of us who have development machines that never see the big bad Internet.

A quick way is to install a kernel with this disabled… i am sure you can find one prebuild somewhere, a sbuilding the kernel on each update is time consuming …

This is a very old topic, but the question remains unanswered.
Apparently there are some kernel parameters one can use to disable some of the mitigations, as they cause sometimes severe performance hits.
Here’s an article about these parameters.


Just in case the link goes dead here are some of the parameters mentioned there:

  • nospectre_v1 (disables spectre mitigations v1 )
  • nospectre_v2 (disables spectre mitigations v2 )
  • nospec_store_bypass_disable (disables spectre mitigations v4 )

Similarily this article here mentions even more mitigation disable parameters:
https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_CPUs

  • noibrs - We don’t need no restricted indirect branch speculation
  • noibpb - We don’t need no indirect branch prediction barrier either
  • nospectre_v1 and nospectre_v2 : Don’t care if some program can get data from some other program when it shouldn’t
  • l1tf=off - Why would we be flushing the L1 cache, we might need that data. So what if anyone can get at it.
  • nospec_store_bypass_disable - Of course we want to use, not bypass, the stored data
  • no_stf_barrier - We don’t need no barriers between software, they could be friends
  • mds=off - Zombieload attacks are fine
  • mitigations=off - Of course we don’t want no mitigations

The security parameters covered by mitigations=off in kernel 5.3.6 are (keep in mind OP was using kernel 5.3.5, no idea if the parameters existed back then, but if he was just keeping his kernel updated, he should be able to use them):

  • nopti [X86,PPC] - Control Page Table Isolation of user and kernel address spaces. Disabling this feature removes hardening, but improves performance of system calls and interrupts.
  • kpti=0 [ARM64] - Control page table isolation of user and kernel address spaces.
  • nobp=0 [S390] - Undocumented. Does something on S390 systems, nobody knows what.
  • nospectre_v1 [X86,PPC] - Disable mitigations for Spectre Variant 1 (bounds check bypass). With this option data leaks are possible in the system.
  • nospectre_v2 [X86,PPC,S390,ARM64] - Disable all mitigations for the Spectre variant 2 (indirect branch prediction) vulnerability. System may allow data leaks with this option.
  • spectre_v2_user=off [X86] - Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability between user space tasks
  • spec_store_bypass_disable=off [X86,PPC] - Control Speculative Store Bypass (SSB) Disable mitigation (Speculative Store Bypass vulnerability)
  • ssbd=force-off [ARM64] - Speculative Store Bypass Disable control
  • l1tf=off [X86] - Control mitigation of the L1TF vulnerability on affected CPUs
  • mds=off [X86] - Control mitigation for the Micro-architectural Data Sampling (MDS) vulnerability.

However according to the last article i posted above, the performcance benefits are really negligible.

image
image

Just ignore the SMT=off bars, as that’s actually disable HyperThreading and nobody does that. Right?

2 Likes

Sorry it’s a really old post but it was advice given to me long ago by the person that got me started on arch Linux. Hope it helps.

1 Like

@Elloquin So I’ve disabled everything i could by adding these parameters to my kernel noibrs noibpb mitigations=off nospec_store_bypass_disable no_stf_barrier audit=0 nowatchdog (the last two parameters taken out of the article you just posted) and made a benchmark before and after, using “System profiler and benchmark” app.
Out of 8 tests just 1 showed some more pronounced difference, and even that difference was only 2.8%.
My conclusion: this is a non-issue. Intel can have its 2% if it thinks that’ll make me more secure.

1 Like

@nate Agreed. I am fully amd personally so I never tested it. Everyone has their own idiosyncrasies when it comes to linux. For example people that strive to make it use as little ram as possible to having the smallest amount of packages installed. To some the small performance boost may be wanted. In the end I agree that it is not that big a hit to sacrifice security. :+1:

1 Like

I’ve kept the audit=0 and nowatchdog parameters though. They are less about security vs performance as they are about removing unneeded functionality on my system.

Audit is supposed to log every syscall on the system. I don’t need it to pollute my logs (as it’s a pain anyway to make sense of what happened and I’m anyway not into that low level debugging), so removing it should be no issue but should shorten boot times and remove [a harder to measure] system performance overhead caused by audit ( https://capsule8.com/blog/auditd-what-is-the-linux-auditing-system/ )
Disabling watchdog should prevent sometimes reboot hanging up to a minute with the watchdog counting up to it’s timer completion on my system. I’ll keep an eye on this to see if this really happens.

1 Like