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.htm...

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 :|