group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #31098
[Bug 1832622] Re: QEMU - count cache flush Spectre v2 mitigation (CVE) (required for POWER9 DD2.3)
This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu1
---------------
qemu (1:4.0+dfsg-0ubuntu1) eoan; urgency=medium
* Merge with Upstream release of qemu 4.0.
Among many other things this fixes LP Bugs:
LP: #1782206 - SnowRidge Accelerator Interfacing Architecture (AIA)
LP: #1828038 - Update s390x CPU Model for more HW support
LP: #1832622 - count cache flush Spectre v2 mitigation for ppc64el
Remaining Changes:
- qemu-kvm to systemd unit
- d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm,
hugepages and architecture specifics
- d/qemu-system-common.qemu-kvm.service: systemd unit to call
qemu-kvm-init
- d/qemu-system-common.install: install helper script
- d/qemu-system-common.maintscript: clean old sysv and upstart scripts
- d/qemu-system-common.qemu-kvm.default: defaults for
/etc/default/qemu-kvm
- d/rules: call dh_installinit and dh_installsystemd for qemu-kvm
- Enable nesting by default
- d/qemu-system-x86.modprobe: set nested=1 module option on intel.
(is default on amd)
- d/qemu-system-x86.postinst: re-load kvm_intel.ko if it was loaded
without nested=1
- d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default
in qemu64 cpu type.
- d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default
in qemu64 on amd
- d/qemu-system-x86.README.Debian: document intention of nested being
default is comfort, not full support
- Distribution specific machine type (LP: 1304107 1621042)
- d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine
types
- d/qemu-system-x86.NEWS Info on fixed machine type defintions
for host-phys-bits=true (LP: 1776189)
- add an info about -hpb machine type in debian/qemu-system-x86.NEWS
- provide pseries-bionic-2.11-sxxm type as convenience with all
meltdown/spectre workarounds enabled by default. (LP: 1761372).
- improved dependencies
- Make qemu-system-common depend on qemu-block-extra
- Make qemu-utils depend on qemu-block-extra
- let qemu-utils recommend sharutils
- s390x support
- Create qemu-system-s390x package
- Enable numa support for s390x
- arch aware kvm wrappers
- d/control: update VCS links
- qemu-guest-agent: freeze-hook fixes (LP: 1484990)
- d/qemu-guest-agent.install: provide /etc/qemu/fsfreeze-hook
- d/qemu-guest-agent.dirs: provide /etc/qemu/fsfreeze-hook.d
- d/control-in: enable RDMA support in qemu (LP: 1692476)
- enable RDMA config option
- add libibumad-dev build-dep
- tolerate ipxe size change on migrations to >=18.04 (LP: 1713490)
- d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types
reference 256k path
- d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to
handle incoming migrations from former releases.
- d/control-in: Disable capstone disassembler library support (universe)
- Move s390x roms to a new qemu-system-data-s390x
- d/qemu-system-data.install: install s390x roms as architecture:all in
qemu-system-data
- d/rules: build s390-ccw.img with upstream Makefile
- d/rules: build s390-netboot.img with upstream Makefile
- d/p/ubuntu/lp-1790901-partial-SLOF-for-s390x-netboot.patch: bring back
some SLOF bits stripped in DFSG to be able to build s390x-netboot roms
As that hack to build s390-ccw.img rom can't build s390x-netboot.img
replace it with a build-indep using the upstream makefiles.
This is less prone to miss future changes/fixes that are done to the
makefiles
- d/control-in: add breaks/replaces for moving s390x roms from
qemu-system-s390x to qemu-system-data
- remove /dev/kvm permission handling (moved to systemd 239-6) (#892945)
[From not yet uploaded Debian branch]
- d/p/debianize-qemu-guest-service.patch: fix path of qemu-ga
- d/rules: fix qemu-kvm service for debhelper compat >=12
- disable pvrdma - besides several security holes there are many other
bugs there as well
* Dropped patches that are upstream in v4.0
- d/p/do-not-link-everything-with-xen.patch
- d/p/usb-mtp-use-O_NOFOLLOW-and-O_CLOEXEC-CVE-2018-16872.patch
- d/p/hw_usb-fix-mistaken-de-initialization-of-CCID-state.patch
- d/p/scsi-generic-avoid-possible-oob-access-to-r-buf-CVE-2019-6501.patch
- d/p/slirp-check-data-length-while-emulating-ident-function-CVE-2019-6778
- d/p/i2c-ddc-fix-oob-read-CVE-2019-3812.patch
- d/p/ubuntu/lp-1759509-qmp-query-current-machine-with-wakeup-suspend-suppor
(LP: 1759509)
- d/p/ubuntu/lp-1759509-qga-update-guest-suspend-ram-and-guest-suspend-hybri
- d/p/ubuntu/lp-1759509-qmp-hmp-Make-system_wakeup-check-wake-up-support-and
- d/p/ubuntu/lp-1812384-s390x-Return-specification-exception-for-unimplement
- d/p/ubuntu/CVE-2018-20815.patch
- d/p/ubuntu/CVE-2019-5008.patch
- d/p/ubuntu/CVE-2019-9824.patch
- d/p/ubuntu/Revert-target-i386-kvm-add-VMX-migration-blocker.patch:
avoid misdetection of simplified nesting blocking all migrations
* Dropped further patches
d/p/bt-use-size_t-type-for-length-parameters-instead-of-int-CVE-2018-19665
[upstream deprecated the whole subsystem instead of applying the fix]
* Added Changes
- updated ubuntu machine types for v4.0
- added eoan types
- fixed s390x issue of upstream types having a "v" prefix
- add back dropped machine types to avoid more issues like LP: 1802944
- fix kvm split irqchip default in ubuntu q35 machine type
- drop no more needed spapr_machine_2_11_sxxm_instance_options and
adapt updated CamelCase
- -hpb types now need to use GlobalProperties
- pc_compat_2_0 got a _fn suffix and slight changes
- d/p/ubuntu/lp-1790901-partial-SLOF-for-s390x-netboot.patch: update to
SLOF of qemu 4.0
- Refreshed patches still needed for v4.0 context changes
- d/p/use-fixed-data-path.patch
- d/p/ubuntu/enable-svm-by-default.patch
- d/p/ubuntu/enable-md-clear.patch
- d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch
- d/p/ubuntu/lp-1830243-*: s390x Secure Linux Boot Toleration
(LP: #1830243)
- d/control: disable bluetooth being deprecated
- d/control*: remove sdlabi which was removed upstream
- d/p/ubuntu/lp-1830238-*: s390x hardware cpu model (LP: #1830238)
- d/control*: enable docs (now explicit) and provide new build-dep
python3-sphinx
- d/not-installed: ignore new interop docs and extra icons for now
- d/not-installed: do not install elf2dmp until namespaced
- d/qemu-utils.install: install new tools qemu-edid and qemu-keymap
- d/qemu-system-data.install: use new paths for formerly used icons
- d/p/ubuntu/linux-user-fix-__NR_semtimedop-undeclared-error.patch:
fix i386 build error
-- Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Mon, 24 Jun
2019 16:33:19 +0200
** Changed in: qemu (Ubuntu Eoan)
Status: Triaged => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-16872
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-19665
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-20815
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-3812
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-5008
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-6501
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-6778
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-9824
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1832622
Title:
QEMU - count cache flush Spectre v2 mitigation (CVE) (required for
POWER9 DD2.3)
Status in The Ubuntu-power-systems project:
Triaged
Status in qemu package in Ubuntu:
Fix Released
Status in qemu source package in Xenial:
Won't Fix
Status in qemu source package in Bionic:
Triaged
Status in qemu source package in Cosmic:
Triaged
Status in qemu source package in Disco:
Triaged
Status in qemu source package in Eoan:
Fix Released
Bug description:
[Impact]
* This belongs to the overall context of spectre mitigations and even
more the try to minimize the related performance impacts.
On ppc64el there is a new chip revision (DD 2.3) which provides
a facility that helps to better mitigate some of this.
* Backport the patches that will make the feature (if supported by the
HW) will pass the capability to the guest - to allow guests that
support the improved mitigation to use it.
[Test Case]
* Start guests with and without this capability
* Check if the capability is guest visible as intented
* Check if there are any issues on pre DD2.3 HW
* Test migrations (IBM outlined the intented paths that will work
below)
* The problem with the above (and also the reasons I didn't add a list
of commands this time) is that it needs special HW (mentioned DD2.3
revision) of the chips which aren't available to us right now.
Due to that testing / verification of this on all releases is on IBM
[Regression Potential]
* Adding new capabilities usually works fine, there are three common
pitfalls which here are the regression potential.
- (severe) the code would announce a capability that isn't really
available. The guest tries to use it and crashes
- (medium) several migration paths especially from systems with the
new cap to older (un-updated systems) will fail. But that applies
to any "from machine with Feature to machine without that feature"
and isn't really a new regression. As outlined by IBM below they
even tried to make it somewhat compatible (by being a new value in
an existing cap)
- (low) the guest will see new caps and or facilities. A really odd
guest could stumble due to that (would actually be a guest bug
then)
Overall all of the above was considered by IBM when developing this
and should be ok. For archive wide SRU considerations, this has NO
effect on non ppc64el.
[Other Info]
* n/a
---
Power9 DD 2.3 CPUs running updated firmware will use a new Spectre
v2 mitigation. The new mitigation improves performance of branch heavy
workloads, but also requires kernel support in order to be fully
secure.
Without the kernel support there is a risk of a Spectre v2 attack
across a process context switch, though it has not been demonstrated
in practice.
QEMU portion - platform definition needs to account for this new
mitigation action.. so attribute for this needs to be added.
In terms of support for virtualisation there are 2 sides, kvm and qemu
support. Patch list for each,
KVM:
2b57ecd0208f KVM: PPC: Book3S: Add count cache flush parameters to kvmppc_get_cpu_char()
This is part of LP1822870 already.
QEMU:
8ff43ee404 target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST
399b2896d4 target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS
The KVM side is upstream as of v5.1-rc1.
The QEMU side is upstream as of v4.0.0-rc0.
In terms of migration the state is as follows.
In order to specify to the guest to use the count cache flush
workaround we use the spapr-cap cap-ibs (indirect branch speculation)
with the value workaround. Previously the only valid values were
broken, fixed-ibs (indirect branch serialisation) and fixed-ccd (count
cache disabled). And add a new cap cap-ccf-assist (count cache flush
assist) to specify the availability of the hardware assisted flush
variant.
Note the the way spapr caps work you can migrate to a host that supports a higher value, but not to one which doesn't support the current value (i.e. only supports lower values). Where for cap-ibs these are defined as:
0 - Broken
1 - Workaround
2 - fixed-ibs
3 - fixed-ccd
So the following migrations would be valid for example:
broken -> fixed-ccd, broken -> workaround, workaround -> fixed-ccd
While the following would be invalid:
fixed-ccd -> workaround, workaround ->broken, fixed-ccd -> broken
This is done to maintain at least the level of protection specified on the command line on migration.
Since the workaround must be communicated to the guest kernel at boot we cannot migrate a guest from a host with fixed-ccd to one with workaround since the guest wouldn't know to do the flush and so would be wholly unprotected.
This means that to migrate a guest from 2.2 and before to 2.3 would
require the guest to either be have been booted with broken
previously, or to be rebooted with workaround specified on the command
line which would allow the migration to succeed to a 2.3.
== MICHAEL D. ROTH ==
I've tested a backport of count-cache-flush support consisting of the following patches applied (cleanly) on top of bionic's QEMU 2.11+dfsg-1ubuntu7.14 source:
target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST
ppc/spapr-caps: Change migration macro to take full spapr-cap name
target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS
target/ppc: Factor out the parsing in kvmppc_get_cpu_characteristics()
The following tests were done using a DD 2.3 Witherspoon machine and
the results seem to align with what's expected in the original
summary:
== enablement tests (using 4.15.0-51-generic in both host and guests)
==
with cap-ibs=workaround,cap-ccf-assist=on:
mdroth@ubuntu:~$ dmesg | grep cache-flush
[ 0.000000] count-cache-flush: hardware assisted flush sequence enabled
with cap-ibs=workaround,cap-ccf-assist=off:
mdroth@ubuntu:~$ dmesg | grep cache-flush
[ 0.000000] count-cache-flush: full software flush sequence enabled.
with cap-ibs=broken
mdroth@ubuntu:~$ dmesg | grep cache-flush
[ 0.000000] count-cache-flush: software flush disabled.
== migration tests (using 4.15.0-51-generic in both host and guests)
==
Note that pseries-2.11-sxxm/bionic-sxxm defaults to:
smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_WORKAROUND;
smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_WORKAROUND;
smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_FIXED_CCD
but SPAPR_CAP_FIXED_CCD is not available on the DD 2.3 system I tested
on (no fw-count-cache-disabled/enabled in host fw-features device
tree), so I used pseries-2.11-sxxm,cap-ibs=broken as the base-level
cross-migration: qemu 2.11+dfsg-1ubuntu7.14 -> 2.11+dfsg-1ubuntu7.14
+ccf-backport
source: -M bionic-sxxm,cap-ibs=broken
target: -M bionic-sxxm,cap-ibs=workaround,cap-ccf-assist=off
expected: warning
actual: warning
"cap-ibs lower level (0) in incoming stream than on destination (1))"
software ccf enabled after reboot? yes
target: -M bionic-sxxm,cap-ibs=workaround,cap-ccf-assist=on
expected: warning
actual: warning
"cap-ccf-assist lower level (0) in incoming stream than on destination (1))"
hardware ccf enabled after reboot? yes
target: -M bionic-sxxm,cap-ibs=broken
expected: success
actual: success
migration: 2.11+dfsg-1ubuntu7.14+ccf-backport -> 2.11+dfsg-1ubuntu7.14
+ccf-backport
source: -M bionic-sxxm,cap-ibs=workaround,cap-ccf-assist=off
target: -M bionic-sxxm,cap-ibs=workaround,cap-ccf-assist=off
expected: success
actual: success
target: -M bionic-sxxm,cap-ibs=workaround,cap-ccf-assist=on
expected: warning
actual: warning
"cap-ccf-assist lower level (0) in incoming stream than on destination (1)"
hardware ccf enabled after reboot? yes
target: -M bionic-sxxm,cap-ibs=broken
expected: fail
actual: fail
"cap-ibs higher level (1) in incoming stream than on destination (0)"
source: -M bionic-sxxm,cap-ibs=workaround,ccf-assist=on
target: -M bionic-sxxm,cap-ibs=workaround,cap-ccf-assist=on
expected: success
actual: success
target: -M bionic-sxxm,cap-ibs=workaround,cap-ccf-assist=off
expected: fail
actual: fail, "cap-ccf-assist higher level (1) in incoming stream than on destination (0)"
target: cap-ibs=broken (expected: fail, actual: )
expected: fail
actual: fail
"cap-ibs higher level (1) in incoming stream than on destination (0)"
"cap-ccf-assist higher level (1) in incoming stream than on destination (0)"
Sorry, I forgot that I needed some fix-ups for the 4th/last patch,
"target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST".
I've gone ahead and posted my git tree, which is based on top of the
qemu_2.11+dfsg-1ubuntu7.14 source, so the 4 patches there should apply
cleanly. There's are notes in the commit notes on what changes were
needed for patch 4.
https://github.com/mdroth/qemu/commits/spectre-ccf-ubuntu-bionic-
1ubuntu7.14
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1832622/+subscriptions
