** Description changed: + [Impact] + + * After the initial fixes relates to Spectre were urgent and sometimes + crude there are more and more refined/improved fixes available now. + For details see + 124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf + attached to https://bugzilla.kernel.org/show_bug.cgi?id=199889 + + * This small change makes those new CPU flags known to libvirt/qemu to + pass them to the guests if wanted. + + + [Test Case] + + * On a system with those flags (newer AMD chips + Firmware updates) + - "virsh capabilities" should report the amd[-no]-ssbd flag + - if also the qemu update is available "virsh domcapabilities" should + list it. + - A guest started as host-model should add the feature to the guest + definition + - The guest should receive the flags (that is hard to see as they are + not in e.g. /proc/cpuinfo, might need some kernel poking) + + [Regression Potential] + + * This makes flags known and some modes will detect and pass all flags to + the guest (e.g. host-model). Due to that a non patched target might not + know about (that is common and ok through those upgrades). + * More interesting (but still preferred to not patching it) is a guest + that handles the use of the mitigation "wrong". Imagine a guest had not + got the flag passed before the fix, now gets it and enables whatever + mitigation that implies. If this mitigation is broken a formerly + working guest would fail. Again this is a common concept through + upgrades of the virt stack which is the reason why usually higher level + apps check the capabilities initially and then model the features. + Those will not change through an upgrade, only new e.g. host-model + guest starts will model it with the new code which then will contain + the new flags. + + [Other Info] + + * n/a + + --- + Newer AMD FW/Chips can provide better ssbd mitigations than the initial virt-ssbd which was already backports as part of the security CVEs back when spectre appeared. The faster mode is described in a document attached to: - https://bugzilla.kernel.org/show_bug.cgi?id=199889 + https://bugzilla.kernel.org/show_bug.cgi?id=199889 In addition via the amd-no-ssb flag chips can declare that they are unaffected and no mitigationas are needed. libvirt commit ver subject 2625722c 4.6 cpu: add 'amd-ssbd' and 'amd-no-ssb' CPU features (CVE-2018-3639) Qemu: a764f3f7 3.0 i386: define the AMD 'amd-ssbd' CPUID feature bit 254790a9 3.0 i386: Define AMD's no SSB mitigation needed. Given that I'd expect Rome chips usage to rise and those have some of them set it makes sense to backport that to the latest LTS at least. Users are already "secure" without that but it will help to get less of a performance hit due to better (or not needed) mitigations. Since the code already is in libvirt 4.6 and qemu 3.0 this is already in recent Ubuntu releases (>=Disco) and only about the SRU. To be combined with the libvirt backports for the intel counterpart in bug 1828495 which needs some pre-work in Eoan at first.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1840745 Title: backport extended amd spectre mitigations To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1840745/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
