Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Disabling security mitigations for speed

Off-Topic discussions about science, technology, and non Debian specific topics.
Post Reply
Message
Author
User avatar
bester69
Posts: 2072
Joined: 2015-04-02 13:15
Has thanked: 24 times
Been thanked: 14 times

Disabling security mitigations for speed

#1 Post by bester69 »

Hi,

I was using this .:
GRUB_CMDLINE_LINUX_DEFAULT="........ nopti noibrs noibpb"
but then I used spectre-meltdown-checker, and saw I had spectre_v2 mitigation path enabled, so I saw It was able to disable it as well.. so Now I disabled it and seems to get some litle speed gain with spectre_v2 disabled.:
GRUB_CMDLINE_LINUX_DEFAULT="........ nospectre_v2 nopti noibrs noibpb"

What else can I disable, and how can I do it?, I saw still some security pathes are in green, among them spectre_v1 and Foreshadow's patches.
sudo spectre-meltdown-checker

Code: Select all

Kernel is Linux 4.4.167-0404167-generic #201812130444 SMP Thu Dec 13 09:47:44 UTC 2018 x86_64                                                                                         
CPU is Genuine Intel(R) CPU             575  @ 2.00GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO 
    * CPU indicates IBRS capability:  NO 
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO 
    * CPU indicates IBPB capability:  NO 
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO 
    * CPU indicates STIBP capability:  NO 
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  NO 
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  NO 
    * CPU indicates L1D flush capability:  NO 
  * 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 (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 supports Software Guard Extensions (SGX):  NO 
  * CPU microcode is known to cause stability problems:  NO  (model 0xf family 0x6 stepping 0xd ucode 0xa4 cpuid 0x6fd)
  * CPU microcode is the latest known available version:  YES  (latest version is 0xa4 dated 2010/10/02 according to builtin MCExtractor DB v84 - 2018/09/27)
* 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):  NO 
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  YES 
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  YES 

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* 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:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES 
    * IBRS enabled and active:  NO 
  * Kernel is compiled with IBPB support:  YES 
    * IBPB enabled and active:  NO 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  YES 
> STATUS:  VULNERABLE  (IBRS+IBPB or retpoline+IBPB 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:  UNKNOWN  (dmesg truncated, please reboot and relaunch this script)
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* 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:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  VULNERABLE  (Your CPU doesn't support SSBD)

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  N/A 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

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

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: 
* This system is a host running an 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 kernel image)
  * L1D flush enabled:  UNKNOWN  (unrecognized mode)
  * Hardware-backed L1D flush supported:  NO  (flush will be done in software, this is slower)
  * Hyper-Threading (SMT) is enabled:  NO 
> STATUS:  NOT VULNERABLE  (this system is not running an hypervisor)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:KO CVE-2017-5754:KO CVE-2018-3640:KO CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK
Thanks.
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...

Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Re: Disabling security mitigations for speed

#2 Post by Deb-fan »

Really just getting into this. Every couple of years the urge to compile a kernel kicks in and so researching this type of thing. Findings so far is this can be kernel version dependent, as of v 4.19 looks like disabling mitigations for Spectre version 1 can be added with "nospectre_v1". Not sure if patches have been backported in Debian. While addressing other mitigations may only be done at compile time. Anyway thanks for sharing info on this as of yet not sure which way I'm going to take on it overall.

Would you mind elaborating in any speed gains and this is just in the course of general desktop computing? Not even touching on any of the somebody shouldn't do this or that. It's your computer and mine is mine. Still want to get more educated in this topic and any impact before making a decision as to how best to approach it.
Most powerful FREE tech-support tool on the planet * HERE. *

User avatar
bester69
Posts: 2072
Joined: 2015-04-02 13:15
Has thanked: 24 times
Been thanked: 14 times

Re: Disabling security mitigations for speed

#3 Post by bester69 »

Deb-fan wrote:Really just getting into this. Every couple of years the urge to compile a kernel kicks in and so researching this type of thing. Findings so far is this can be kernel version dependent, as of v 4.19 looks like disabling mitigations for Spectre version 1 can be added with "nospectre_v1". Not sure if patches have been backported in Debian. While addressing other mitigations may only be done at compile time. Anyway thanks for sharing info on this as of yet not sure which way I'm going to take on it overall.

Would you mind elaborating in any speed gains and this is just in the course of general desktop computing? Not even touching on any of the somebody shouldn't do this or that. It's your computer and mine is mine. Still want to get more educated in this topic and any impact before making a decision as to how best to approach it.
ok, I kept spectre_v2 disabled, I feel the system a litle bit faster or smoother responsive, but it might be bias fealing OP.. I dont go for benchmarks as they dont usually help me with gains on desktop response/fealings, so Ive to trust my own senses to keep the change or discard it, and I believe Im good on that. All of this because my system is very old (2008's laptop) and litle changes put it into obsolescence gap.
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...

Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Re: Disabling security mitigations for speed

#4 Post by Deb-fan »

^Thanks, have a dinosaur laptop too. You've got me by a bit (2009) am happy with it though. Keep up the tweak efforts. :)
Most powerful FREE tech-support tool on the planet * HERE. *

Post Reply