backport extended amd spectre mitigations
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Christian Ehrhardt | ||
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Christian Ehrhardt |
Bug Description
[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_
attached to https:/
* 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:/
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.
Changed in libvirt (Ubuntu): | |
status: | New → Fix Released |
Changed in qemu (Ubuntu): | |
status: | New → Fix Released |
Changed in libvirt (Ubuntu Bionic): | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in qemu (Ubuntu Bionic): | |
importance: | Undecided → Medium |
status: | New → Triaged |
assignee: | nobody → Christian Ehrhardt (paelzer) |
Changed in libvirt (Ubuntu Bionic): | |
assignee: | nobody → Christian Ehrhardt (paelzer) |
description: | updated |
Changes reviewed and tested in the regression test set over night (combined with the other changes I intend to group on the SRU). Uploaded (qmeu&libvirt) to -unapproved for the SRU team to consider.