Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Temporarily disable spectre/metdown mitigations
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
msst
Apprentice
Apprentice


Joined: 07 Jun 2011
Posts: 241

PostPosted: Tue Feb 25, 2020 6:14 pm    Post subject: Temporarily disable spectre/metdown mitigations Reply with quote

During the last lengthy compile session I was wondering if there is actually an easy way to temporarily disable these mitigation on a desktop computer?

In short I would want to gain some extra compile speed while it is needed and then have it re-enabled. I don't see any security risk with it if the box is used only by me and doing nothing else than running the compile job...
Back to top
View user's profile Send private message
Ionen
Guru
Guru


Joined: 06 Dec 2018
Posts: 525

PostPosted: Tue Feb 25, 2020 6:19 pm    Post subject: Reply with quote

Since kernel 5.2 or so, there's a all-in-one disable switch that can be passed to kernel boot parameters (mitigations=off), if you don't mind rebooting to switch. I don't think it can be turned on/off while already running if that's what you were hoping for.
Back to top
View user's profile Send private message
CaptainBlood
Veteran
Veteran


Joined: 24 Jan 2010
Posts: 1428

PostPosted: Tue Feb 25, 2020 7:17 pm    Post subject: Reply with quote

Lttle tool that allows to inspect current vulnerabilities/mitigations status:
Code:
uname -r
5.5.5-gentoo-classic
which has been compiled with all mitigations activated(afaik), but deactivated at bootstrap.
Code:
/usr/bin/spectre-meltdown-checker
Spectre and Meltdown mitigation detection tool v0.43

Checking for vulnerabilities on current system
Kernel is Linux 5.5.5-gentoo-classic #4 SMP PREEMPT Sat Feb 22 12:59:09 EAT 2020 x86_64
CPU is Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  YES  (Intel SSBD)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  YES
    * CPU indicates L1D flush capability:  YES  (L1D flush feature bit)
  * Microarchitectural Data Sampling
    * VERW instruction is available:  YES  (MD_CLEAR feature bit)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO):  NO
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system:  NO
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDS_NO):  NO
  * CPU explicitly indicates not being vulnerable to TSX Asynchronous Abort (TAA_NO):  NO
  * CPU explicitly indicates not being vulnerable to iTLB Multihit (PSCHANGE_MSC_NO):  NO
  * CPU explicitly indicates having MSR for TSX control (TSX_CTRL_MSR):  NO
  * CPU supports Transactional Synchronization Extensions (TSX):  NO
  * CPU supports Software Guard Extensions (SGX):  YES
  * CPU microcode is known to cause stability problems:  NO  (model 0x5e family 0x6 stepping 0x3 ucode 0xd6 cpuid 0x506e3)
  * CPU microcode is the latest known available version:  YES  (latest version is 0xd6 dated 2019/10/03 according to builtin firmwares DB v130.20191104+i20191027)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  YES
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read):  YES
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass):  YES
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  YES
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  YES
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  YES
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)):  YES
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)):  YES
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)):  YES
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)):  YES
  * Vulnerable to CVE-2019-11135 (ZombieLoad V2, TSX Asynchronous Abort (TAA)):  NO
  * Vulnerable to CVE-2018-12207 (No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)):  YES

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  NO  (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO
* Kernel has mask_nospec64 (arm64):  NO
> STATUS:  VULNERABLE  (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  NO  (Vulnerable, IBPB: disabled, STIBP: disabled)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES
    * IBRS enabled and active:  UNKNOWN
  * Kernel is compiled with IBPB support:  YES
    * IBPB enabled and active:  YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  YES
  * Kernel supports RSB filling:  YES
> STATUS:  VULNERABLE  (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports Page Table Isolation (PTI):  YES
  * PTI enabled and active:  NO
  * Reduced performance impact of PTI:  YES  (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU:  NO
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  YES
> STATUS:  NOT VULNERABLE  (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)
* SSB mitigation is enabled and active:  NO
> STATUS:  VULNERABLE  (your CPU and kernel both support SSBD but the mitigation is not active)

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  YES
> STATUS:  NOT VULNERABLE  (your CPU microcode mitigates the vulnerability)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTE Inversion)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  YES
> STATUS:  NOT VULNERABLE  (Mitigation: PTE Inversion)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: Mitigation: PTE Inversion
* This system is a host running a hypervisor:  NO
* Mitigation 1 (KVM)
  * EPT is disabled:  N/A  (the kvm_intel module is not loaded)
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in /proc/cpuinfo)
  * L1D flush enabled:  UNKNOWN  (unrecognized mode)
  * Hardware-backed L1D flush supported:  YES  (performance impact of the mitigation will be greatly reduced)
  * Hyper-Threading (SMT) is enabled:  YES
> STATUS:  NOT VULNERABLE  (this system is not running a hypervisor)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  NO  (Vulnerable; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  NO  (Vulnerable; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  NO  (Vulnerable; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  NO  (Vulnerable; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active)

CVE-2019-11135 aka 'ZombieLoad V2, TSX Asynchronous Abort (TAA)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* TAA mitigation is supported by kernel:  YES  (found tsx_async_abort in kernel image)
* TAA mitigation enabled and active:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12207 aka 'No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)'
* Mitigated according to the /sys interface:  UNKNOWN  (Processor vulnerable)
* This system is a host running a hypervisor:  NO
* iTLB Multihit mitigation is supported by kernel:  YES  (found itlb_multihit in kernel image)
* iTLB Multihit mitigation enabled and active:  NO
> STATUS:  NOT VULNERABLE  (this system is not running a hypervisor)

> SUMMARY: CVE-2017-5753:KO CVE-2017-5715:KO CVE-2017-5754:KO CVE-2018-3640:OK CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO CVE-2019-11135:OK CVE-2018-12207:OK

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer
Thks 4 ur attention, interest & support.
Back to top
View user's profile Send private message
axl
l33t
l33t


Joined: 11 Oct 2002
Posts: 908
Location: Romania

PostPosted: Tue Feb 25, 2020 10:18 pm    Post subject: Re: Temporarily disable spectre/metdown mitigations Reply with quote

msst wrote:
During the last lengthy compile session I was wondering if there is actually an easy way to temporarily disable these mitigation on a desktop computer?

In short I would want to gain some extra compile speed while it is needed and then have it re-enabled. I don't see any security risk with it if the box is used only by me and doing nothing else than running the compile job...


kernel parameters.

mitigations=off and mds=off, or things like auto or auto,nosmp.

mitigations are for spectre and meltdown, mds for the new class of bugs. either ways this is just a part of it. second part of avoiding mitigations would be to avoid the intel firmware thingie. both things slow down a system.
Back to top
View user's profile Send private message
CaptainBlood
Veteran
Veteran


Joined: 24 Jan 2010
Posts: 1428

PostPosted: Wed Feb 26, 2020 6:05 am    Post subject: Reply with quote

Code:
mitigations=
                        [X86,PPC,S390,ARM64] Control optional mitigations for
                        CPU vulnerabilities.  This is a set of curated,
                        arch-independent options, each of which is an
                        aggregation of existing arch-specific options.

                        off
                                Disable all optional CPU mitigations.  This
                                improves system performance, but it may also
                                expose users to several CPU vulnerabilities.
                                Equivalent to: nopti [X86,PPC]
                                               kpti=0 [ARM64]
                                               nospectre_v1 [X86,PPC]
                                               nobp=0 [S390]
                                               nospectre_v2 [X86,PPC,S390,ARM64]
                                               spectre_v2_user=off [X86]
                                               spec_store_bypass_disable=off [X86,PPC]
                                               ssbd=force-off [ARM64]
                                               l1tf=off [X86]
                                               mds=off [X86]
                                               tsx_async_abort=off [X86]
                                               kvm.nx_huge_pages=off [X86]

                                Exceptions:
                                               This does not have any effect on
                                               kvm.nx_huge_pages when
                                               kvm.nx_huge_pages=force.

                        auto (default)
                                Mitigate all CPU vulnerabilities, but leave SMT
                                enabled, even if it's vulnerable.  This is for
                                users who don't want to be surprised by SMT
                                getting disabled across kernel upgrades, or who
                                have other ways of avoiding SMT-based attacks.
                                Equivalent to: (default behavior)

                        auto,nosmt
                                Mitigate all CPU vulnerabilities, disabling SMT
                                if needed.  This is for users who always want to
                                be fully mitigated, even if it means losing SMT.
                                Equivalent to: l1tf=flush,nosmt [X86]
                                               mds=full,nosmt [X86]
                                               tsx_async_abort=full,nosmt [X86]
Code:
mds=            [X86,INTEL]
                        Control mitigation for the Micro-architectural Data
                        Sampling (MDS) vulnerability.

                        Certain CPUs are vulnerable to an exploit against CPU
                        internal buffers which can forward information to a
                        disclosure gadget under certain conditions.

                        In vulnerable processors, the speculatively
                        forwarded data can be used in a cache side channel
                        attack, to access data to which the attacker does
                        not have direct access.

                        This parameter controls the MDS mitigation. The
                        options are:

                        full       - Enable MDS mitigation on vulnerable CPUs
                        full,nosmt - Enable MDS mitigation and disable
                                     SMT on vulnerable CPUs
                        off        - Unconditionally disable MDS mitigation

                        On TAA-affected machines, mds=off can be prevented by
                        an active TAA mitigation as both vulnerabilities are
                        mitigated with the same mechanism so in order to disable
                        this mitigation, you need to specify tsx_async_abort=off
                        too.

                        Not specifying this option is equivalent to
                        mds=full.
There may be more here
Thks 4 ur attention, interest & support
Back to top
View user's profile Send private message
msst
Apprentice
Apprentice


Joined: 07 Jun 2011
Posts: 241

PostPosted: Sun Mar 01, 2020 12:45 pm    Post subject: Reply with quote

Quote:
if you don't mind rebooting to switch


I do. I want to disable it just before the compile and enable then just thereafter. Rather annoying having to reboot the desktop twice for this. Ideally I want to do something like

Code:

echo "off" > /proc/sys/kernel/mitigations


But of course there is no mitigations switch under proc afaik...
Back to top
View user's profile Send private message
axl
l33t
l33t


Joined: 11 Oct 2002
Posts: 908
Location: Romania

PostPosted: Sun Mar 01, 2020 10:08 pm    Post subject: Reply with quote

I don't think there's a way for a cpu to unlearn the microcode that was uploaded into it, which is part of the "fix" for mitigations. so yeah, you would have to reboot.

You could go from non-mitigated state to mitigated state, by loading the microcode. but I dont think there's a way back. It's not the kernel, its the cpu.
Back to top
View user's profile Send private message
axl
l33t
l33t


Joined: 11 Oct 2002
Posts: 908
Location: Romania

PostPosted: Sun Mar 01, 2020 10:12 pm    Post subject: Reply with quote

if there was a way to clear the microcode and just remove protection by just manipulating the kernel, it would reverse the need for a microcode in the first place. because, that's what that microcode is doing essentially. so there is that.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum