[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Should all kernel patches for CPU bugs be unconditionally enabled? Vs Performance vs Applicability

Should all kernel patches for CPU bugs be unconditionally enabled? We currently enable all of the mds vulnerability mitigations.

Setting spectre_v2=on as a boot parameter will force the spectre v2 mitigation to be enabled.

l1tf=full,force will enable all mitigations for the L1TF vulnerability and disable smt (which is already disabled with the mds mitigations).

spec_store_bypass_disable=on will enable the SSB vulnerability mitigation (spectre v4). ClipOS recommends to use spec_store_bypass_disable=seccomp which disables the mitigation by default but enables it for programs using seccomp.

This should also partly get rid of the need for microcode updates.

spectre-meltdown-checker reports that disabling EPT would mitigate L1TF. EPT can be disabled with kvm-intel.ept=0 (I think). Does anyone know more about this?

I just found https://www.kernel.org/doc/html/v4.19/admin-guide/l1tf.html

  1. Disabling EPT

Disabling EPT for virtual machines provides full mitigation for L1TF even with SMT enabled, because the effective page tables for guests are managed and sanitized by the hypervisor. Though disabling EPT has a significant performance impact especially when the Meltdown mitigation KPTI is enabled.

EPT can be disabled in the hypervisor via the ‘kvm-intel.ept’ parameter.

This sounds like something that should be disabled.

Do we care enough about performance to go through with these?

Related:

1 Like

From perspective of security-misc on a host:

  • Will machines get slower, that are patched (kernel, microcode) already?

From perspective of VMs with security-misc installed:

  • Will VMs get slower, where host, VM kernel, hypervisor, microcode is fully patched already?

What i the rationale for unconditionally enable i.e. setting to on? Why not leave it at auto?

  • on - Unconditionally enable mitigations. Is enforced by spectre_v2=on

  • Not specifying this option is equivalent to spectre_v2=auto.

Whonix VirtualBox: For VirtualBox this currently would only result in slow down:
https://www.whonix.org/wiki/Spectre_Meltdown#VirtualBox

Qubes: up to Qubes, should be fixed by Qubes.

Whonix KVM: Status? @HulaHoop

Debian based hosts using security-misc package: auto should do?

What’s the rationale of not applying microcode updates?
You think we should protect users who don’t know about microcode updates? Probably many. In that case, auto should do?
A way to protect them will also be “hardened debian” where we could automate running spectre-meltdown-checker on the host through “whonixcheck”.
Related:
https://phabricator.whonix.org/T827

1 Like

Likely not. If they’re already applying patches then security-misc will just make sure they are applied.

If the host is already patched then the VMs won’t get slower as the VMs would be trying to patch something that is already patched so it won’t do anything.

If the kernel doesn’t properly detect if the CPU is vulnerable or not then the patches won’t be applied. This is especially problematic for people who use KVM as their hypervisor as it spoofs the host’s CPU model so the kernel in a VM has no way to know that the CPU is vulnerable, thus the patches won’t be applied.

Enabling all mitigations may also prevent unknown bugs. For example, smt seems to be a big part in many of these CPU bugs.

Whonix can’t apply microcode updates from VMs. This way we are protected from the CPU bugs without having to touch the host.

Also, some people may not want to install proprietary software. This is even worse for people using OSes like Parabola, PureOS or any other OS trying to be completely free as it won’t allow the user to install microcode updates.

Yes.

That depends. See my reasons above.

If not in a KVM VM or any other VM that spoofs the CPU model then auto should be ok.

1 Like

madaidan via Whonix Forum:

If the kernel doesn’t properly detect if the CPU is vulnerable or not then the patches won’t be applied.

How likely is that? Happening already? Would spectre-meltdown-checker
catch that?

This is especially problematic for people who use KVM as their hypervisor as it spoofs the host’s CPU model so the kernel in a VM has no way to know that the CPU is vulnerable, thus the patches won’t be applied.

HulaHoop changed Whonix KVM to host-passthrough:

https://github.com/Whonix/whonix-libvirt/blob/master/usr/share/whonix-libvirt/xml/Whonix-Gateway.xml

<cpu mode='host-passthrough'/>

Was discussed somewhere here also:

Also, some people may not want to install proprietary software. This is even worse for people using OSes like Parabola, PureOS or any other OS trying to be completely free as it won’t allow the user to install microcode updates.

I find this unreasonable. They do run proprietary software anyhow,
perhaps without knowing. Either, they’re running the unpatched nonfree
pre-installed CPU microcode and Intel AMT or AMD PSP or they’re running
the patches nonfree equivalents. Of these two evils, the patched nonfree
equivalent are better.

1 Like

Not sure. I’ve never heard of it happening. It should only happen if the CPU model is somehow being spoofed.

Should the wiki page be updated then?

I agree. These people just don’t seem to understand that.

1 Like

Yes.

1 Like

AFAIK Linux enables the mitigations by default whenever possible using auto. Debian also backported patches against mds. [1]

It is only recently (Linux v5.2) that there is a unified switch for disabling all mitigations for performance on machines not facing the network.[2]

[1] https://news.softpedia.com/news/debian-patches-new-intel-mds-security-vulnerabilities-in-debian-linux-stretch-526047.shtml

[2] https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Meltdown-Easy-Switch-52

Not really. In the case of MDS microcode is needed to be of any effect.

IMPORTANT: There is no software fallback mechanism available for processors that have not received microcode updates from Intel. Mitigation is only possible if Intel has provided a microcode update for your processor.

I really don’t think we should mess with the default spectre/meltdown kernel switches in this case as upstream is clearly aware of the problem and is taking appropriate action. Non defaults will confuse users and might leave them to other attacks they are otherwise safe from.

EPT is the Virtualization hardware solution for safe and fast memory isolation allowing deprecation of shadow page tables done in software for hypervisors You don’t want to disable this.

Yes everything should be left as is. It comes as auto by default. The KVM guest kernel will enforce whenever it detects the necessary microcode extensions are activated.

2 Likes