Sacrificing 30% of my CPU performance (by disabling Hyper-Threading) to fully mitigate CPU vulnerabilities, necessary?

Question

I used the spectre-meltdown-checker, version 0.42, without any option resulting in all-green results. But, in a help page, I found the --paranoid switch, which resulted in about a half of later CVEs to become red. I read what it told me, that for full mitigation I would have to disable hyper-threading, it scared me off a little bit, so I better did so, resulting in only one remaining red flag (CVE-2018-3646 = L1D unconditional flushing should be enabled to fully mitigate the vulnerability).

I use Linux Mint 19.2 as my primary OS and do not spend any actually measurable time in Windows 10 Pro 1903, but I don't know any better benchmarks than those for Windows, anyway, I just ran a series of very quick measurements with and without Hyper-Threading, and it seems to cut me off about 20-30% of performance (did not know it matters that much, but going on). Since I obviously would better be for the more performance, I fail to understand why Hyper-Threading has become such a security hole. Anyway, I have a different and hopefully straight question for you on the bottom.

---

Laptop: Dell Inspiron 15 with latest BIOS (1.8.0, link for details).

Processor: Intel© Core™ i7-7700HQ (link to Intel Ark).

Linux Kernel: 4.15.0-65-generic; full uname -a:

Linux dell-7577 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

For completeness, I add info from the help on the --paranoid switch:

--paranoid      require IBPB to deem Variant 2 as mitigated
                also require SMT disabled + unconditional L1D flush to deem Foreshadow-NG VMM as mitigated
                also require SMT disabled to deem MDS vulnerabilities mitigated

---

Actual question

Is there any other way out of those vulnerabilities, like upgrading to another version of the kernel, or waiting for new BIOS, or is this result final in a sense it can't be remedied by BIOS updates or OS kernel or anything like that?

---

With Hyper-Threading enabled, it shows this:

Spectre and Meltdown mitigation detection tool v0.42

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64
CPU is Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz

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)
  * Microarchitecture 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 supports Software Guard Extensions (SGX):  YES 
  * CPU microcode is known to cause stability problems:  NO  (model 0x9e family 0x6 stepping 0x9 ucode 0xb4 cpuid 0x906e9)
  * CPU microcode is the latest known available version:  YES  (latest version is 0xb4 dated 2019/04/01 according to builtin MCExtractor DB v111 - 2019/05/18)
* 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 

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

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES 
    * IBRS enabled and active:  YES  (for firmware code only)
  * 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 compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
  * Kernel supports RSB filling:  YES 
> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES 
  * PTI enabled and active:  YES 
  * 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:  NOT VULNERABLE  (Mitigation: PTI)

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:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)
* SSB mitigation is enabled and active:  YES  (per-thread through prctl)
* SSB mitigation currently active for selected processes:  YES  (ModemManager systemd-journald systemd-localed systemd-logind systemd-resolved systemd-timesyncd systemd-udevd vnstatd)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

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; VMX: conditional cache flushes, SMT vulnerable)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
* This system is a host running a hypervisor:  YES  (paranoid mode)
* Mitigation 1 (KVM)
  * EPT is disabled:  NO 
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in /proc/cpuinfo)
  * L1D flush enabled:  YES  (conditional flushes)
  * Hardware-backed L1D flush supported:  YES  (performance impact of the mitigation will be greatly reduced)
  * Hyper-Threading (SMT) is enabled:  YES 
> STATUS:  VULNERABLE  (enable L1D unconditional flushing and disable Hyper-Threading to fully mitigate the vulnerability)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES 
* SMT is either mitigated or disabled:  NO 
> STATUS:  VULNERABLE  (Your kernel and microcode partially mitigate the vulnerability, but you must disable SMT (Hyper-Threading) for a complete mitigation)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES 
* SMT is either mitigated or disabled:  NO 
> STATUS:  VULNERABLE  (Your kernel and microcode partially mitigate the vulnerability, but you must disable SMT (Hyper-Threading) for a complete mitigation)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES 
* SMT is either mitigated or disabled:  NO 
> STATUS:  VULNERABLE  (Your kernel and microcode partially mitigate the vulnerability, but you must disable SMT (Hyper-Threading) for a complete mitigation)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT vulnerable)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES 
* SMT is either mitigated or disabled:  NO 
> STATUS:  VULNERABLE  (Your kernel and microcode partially mitigate the vulnerability, but you must disable SMT (Hyper-Threading) for a complete mitigation)

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

---

An image in UHD, can be enlarged:

Answer 1

The short answer is: Yes, but only if you need to be that secure.

The side-channel vulnerabilities are a variety of ways that software can determine what data exists in places that it should not have access to---either by reading it directly or by inference. There are a variety of approaches to prevent this, but the nature of the barrier is determined by the security design of the system and the method of attack.

Most common is an approach where low-level software (firmware, kernel) inhibits any threads/applications from sending dangerous instruction streams, or else they tweak the execution environment slightly to render those streams harmless. This often has a performance impact, and the security improvement is usually worth the cost. However, if it isn't worth the performance hit, you can disable those mitigations---more performance and less security is always an option.

As an example, the Meltdown protection recognizes that there is no protection possible when kernel data is present in user-accessible memory, so it keeps sensitive memory pages out of the user context entirely. There is a performance penalty, but mitigation is entirely possible in software. If Intel fixes the problem in hardware later, KPTI can be disabled.

The more intrusive method is to disable the CPU functionality that causes the vulnerability in the first place. In a sense, we are lucky that this is an option in the first place---many CPU features are not configurable at all. You can choose how many threads each core will execute simultaneously, but you cannot configure the number of dispatch ports or renaming registers.

For some Spectre variants, there is no viable software barrier on Intel CPUs. Disabling hyperthreading eliminates the risk in current CPUs; meanwhile, Intel is designing new CPUs that will not be vulnerable to the current attacks.

It does not seem possible to develop complete microcode, BIOS, or kernel mitigations for those vulnerabilities---the best minds in the industry have determined that it is not feasible. This makes disabling the feature necessary if you want to be secure from that method of attack. I certainly do not have the expertise to develop a better solution.

And note that for virtual environments, the hypervisor may mitigate the risks somewhat as well (e.g., VMware's SCAv2 CPU scheduler). If your host has SCAv2 or equivalent protection, then you can leave hyperthreading enabled without risking exploitation by other VMs---only processes running on that same VM pose a threat.

This is fundamentally a question of risk acceptance: Given the manner in which those vulnerabilities can be exploited (somewhat difficult; local access required for the most part), it is worth a 30% performance loss?

In a cloud environment where strangers may be sharing your CPUs, the risk is more significant than a locally-administered environment where you enforce an application whitelist.

Security is a spectrum, and it must be balanced in light of all relevant factors: the value of your data, your environment, your performance requirements, and financial considerations.