This has to remain future work. While there are many researchers find out more and more attacks and kernel developers invent mitigations, there seems to be a severe shortage of people who are working on analysis tools such as spectre-meltdown-checker or enabling mitigations for as many users as easily as possible. Such as through installation of a package such as security-misc or a distribution such as Kicksecure or Whonix-Host. I am not aware of anyone else working on that currently. There are way too many vulnerabilities, mitigations, use scenarios, processors and therefore resulting combinations which makes this hard to implement.
For start, we could use a wiki table with an overview. Not even sure yet what contents such as table would need. Vulnerabilities, mitigations, use scenarios, processor(s) (families), locally exploitable, remotely exploitable, local information leak, remote information leak (NetSpectre), relevant when using a hypervisor vs not using a hypervisor.
Qubes disabled HT.
( Safe use of Hyperthreading when Xen stable includes new sched-gran parameter · Issue #5547 · QubesOS/qubes-issues · GitHub )
Performance is OK for me with disabled HT but it’s a powerful machine.
I think we should disable HT. Qubes disables it too.
Quote Red Hat Customer Portal - Access to 24x7 support and knowledge
Recent Intel CPU vulnerabilities (L1TF and MDS) cannot be fully mitigated in software without disabling Simultaneous Multi-Threading.
Therefore we better disable it.
This can have a substantial performance impact and is only necessary for certain workloads, so for compatibility reasons, SMT is enabled by default.
I guess for good security, switch from Windows to a Linux distribution. And I guess for advanced security, use Whonix, Whonix-Host, Kicksecure. For our target user it seems appropriate to disable SMT.
In addition, the Intel TAA vulnerability cannot be fully mitigated without disabling either of SMT or the Transactional Synchronization Extensions (TSX).
SMT and TSX should be disabled on affected Intel processors under the following circumstances:
- A bare-metal host runs untrusted virtual machines, and other arrangements have not been made for mitigation.
- A bare-metal host runs untrusted code outside a virtual machine.
In our threat model we deem most code untrusted. We don’t want to trust any code but sometimes we have to. That’s why we use linux user account separation and mandatory access controls. Because some code is considered not deliberately malicious (such as the browser) but potentially exploitable (therefore considered untrusted). Therefore I think “runs untrusted code outside a virtual machine” always applies in our threat model.
Otherwise also things would be more complicated.
Kicksecure users not using a hypervisor: no need to disable SMTWhonix host users running VMs: should disable SMT
SMT can be conditionally disabled by passing mitigations=auto,nosmt on the kernel command line. This will disable SMT only if required for mitigating a vulnerability. This approach has two caveats:
- It does not protect against unknown vulnerabilities in SMT.
I guess at the quantity and speed at which vulnerabilities are published we again ought to disable SMT here.
Alternatively, SMT can be unconditionally disabled by passing nosmt on the kernel command line. This provides the most protection and avoids possible behavior changes on upgrades, at the cost of a potentially unnecessary reduction in performance.