Spectre / meltdown / ... mitigations: Host OS, VM-CPU, VM-OS, ...

[binaryanomaly]

Hi,

I have a question regarding required mitigation measures against spectre / meltdown / ... on different levels, i.e. what is needed where.

As I understand it, already the host OS - Debian contains mitigations according to lscpu output:

Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected

In addition there's the possibility to configure spectre / meltdown migitation measures in the VM-CPU configuration of Proxmox.

1. Is this in addition to the mitigation measures already present on the host required?
2. Why and which ones?

In addition some VMs / software distributions allow to configure spectre mitigations inside the VM-OS as well

1. I guess this is not required and redundant, correct?
2. Or is it that due to virtualization that the virtual CPU itself is affected by spectre even if the host CPU mitigates it already?

It would be helpful to understand what mitigations are required at what level and why.
If everything is activated this is likely redundant and comes with significant waste of resources?

How is it with LXC containers, I reckon host mitigations are enough?

Thanks for insights.

 

[mikeinnyc]

What do "affected", "vulnerable" and "mitigated" mean exactly?​

• Affected means that your CPU's hardware, as it went out of the factory, is known to be concerned by a specific vulnerability, i.e. the vulnerability applies to your hardware model. Note that it says nothing about whether a given vulnerability can actually be used to exploit your system. However, an unaffected CPU will never be vulnerable, and doesn't need to have mitigations in place.
• Vulnerable implies that you're using an affected CPU, and means that a given vulnerability can be exploited on your system, because no (or insufficient) mitigations are in place.
• Mitigated implies that a previously vulnerable system has followed all the steps (updated all the required layers) to ensure a given vulnerability cannot be exploited. About what "layers" mean, see the previous question.

I have many questions too BUT when I run https://github.com/speed47/spectre-meltdown-checker/blob/master/FAQ.md

It comes out Not Vulnerable so I'm reminded by code "A false sense of security is worse than no security at all." We definitely update the "HOST for LXC" However, the guest VM has no microcode of it's own, but you need to update the microcode in the host.
If you want info overload https://arxiv.org/pdf/1811.05441.pdf

Did you update your cpu microcodes?

Did you run Spectre & Meltdown Checker

I just did and it fixed plenty with my E7-8880v2. It was a mess w/o the microcode
From the above link
To mitigate attacks across logical cores, Intel supplied a microcode update to ensure that different SGX attestation
keys are derived when hyperthreading is enabled or disabled.To ensure that no non-SMM software runs while data belong-
ing to SMM are in the L1 data cache, SMM software must rendezvous all logical cores upon entry and exit. According
to Intel, this is expected to be the default behavior for most SMM software [34]. To protect against Foreshadow-NG at-
tacks when hyperthreading is enabled, the hypervisor must ensure that no hypervisor thread runs on a sibling core with
an untrusted VM.

Spectre and Meltdown can be leveraged by attackers to escape software containers, paravirtualized systems, and virtual machines.

I reckon host mitigations are enough? Yes, but we do know VMs are for going rouge untrusted players, unlike LXC which share the Debian resources.

Hardware vulnerability:

• Can be fixed? No, only mitigated (or buy new hardware!)
• How to fix mitigate? In the worst case scenario, 5 "layers" need to be updated: the microcode/firmware, the host OS kernel, the hypervisor, the VM OS kernel, and possibly all the software running on the VM.
• The mitigations aren't in the microcode, they are in the kernel.

Try to update your MC