Re: [libvirt-users] Intel's latest L1TF vulnerability and libvirt
On Tue, Sep 04, 2018 at 11:11:30AM -0700, Paul O'Rorke wrote:
Hi,
with regards Intels L1TF vulnerabilities, it seems they are somewhat
non-committal on whether turning off HyperThreading is required, suggesting
people
> Consult with your hypervisor vendor for more guidance.
https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf....
What is the consensus in the Libvirt community about the risks (or not) of
leaving Hyperthreading enabled? After updates my hosts are showing they
have conditional cache flushing enabled yet still report as "SMT
vulnerable":
root@trk-kvm-03:~# cat /sys/devices/system/cpu/vulnerabilities/l1tf
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
Thoughts?
You should consider hyperthreading *unsafe*, unless you strictly pin all
VMs on the host such that each pair of SMT siblings can only be used by
vCPUs from a single VM at any time. You also have to pin OS services so
that non-VM processes can't be run on HT siblings that are being used by
VMs. Even if you do this, if QEMU non-VCPU threads are running on the HT
siblings there might be risk if those non-VCPU threads hold secrets that
should be isolated from the guest.
Strictly pinning VMs to CPU is a rather painful administrative burden for
users and/or mgmt apps, as well as preventing overcommit, so reducing how
many VMs you can run per host. I expect these factors make it non-viable
for many/most cases, leaving disabling SMT as the only remaining option.
If you've not already seen it there's some more info here that might be
of use in understanding L1TF mitigations:
https://access.redhat.com/security/vulnerabilities/L1TF
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|