[KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.

Bug #1828495 reported by quanxian on 2019-05-10
36
This bug affects 2 people
Affects Status Importance Assigned to Milestone
intel
Undecided
Unassigned
linux (Ubuntu)
Status tracked in Eoan
Bionic
Wishlist
Unassigned
Cosmic
Wishlist
Unassigned
Disco
Wishlist
Unassigned
Eoan
Wishlist
Unassigned
qemu (Ubuntu)
Status tracked in Eoan
Bionic
Wishlist
Rafael David Tinoco
Cosmic
Wishlist
Rafael David Tinoco
Disco
Wishlist
Rafael David Tinoco
Eoan
Wishlist
Unassigned

Bug Description

[Impact]

 * QEMU does not support IceLake and CascadeLake CPUs specific features.
 * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR.
 * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations:
   - Rogue Data Cache Load
   - Enhanced IBRS
   - RSB Alternate
   - L1D flush need on VMENTRY
   - speculative Store Bypass
   to guests, as described in document:
   Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf

[Test Case]

 * From Original Description:

"""
1. Boot up guest using: -cpu Cascadelake-Server

[root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio

char device redirected to /dev/pts/3 (label serial0)

qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4]

qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4]

qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4]

qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4]

2. To check CPU ID related to features[FEAT_7_0_EDX] :CPUID_7_0_EDX_ARCH_CAPABILITIES

Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be 1.

Actual Result:

Host's cpuid: 0x00000007 0x00: eax=0x00000000 ebx=0xd39ffffb ecx=0x00000818 edx=0xbc000000 (EDX bit 29=1)

Guest's cpuid : 0x00000007 0x00: eax=0x00000000 ebx=0xd19f0fb9 ecx=0x00000818 edx=0x84000000 (EDX bit 29=0)

Commit:2bdb76c015df7125783d8394d6339d181cb5bc30

Target Kerned: 5.1
Target Release: 19.10

"""

[Regression Potential]

 * Most changes are related to CPU type definitions and its supported features. They are all based in upstream changes but, for obvious reasons, backporting and/or cherry-picking those could bring issues. Biggest concern is breaking something that currently works. Right now, the parts being changed that could affect other CPU types would be related to a small refactoring of how the features are organized, and that would be seen right away when trying to start a new VM after the package is installed.

 * Other tests, related to the features being backported, are being done by our KVM regression tests, including migration combinations, to reduce chances that a regression is introduced.

[Other Info]

 * N/A

Related branches

quanxian (quanxian-wang) wrote :

Commit:2bdb76c015df7125783d8394d6339d181cb5bc30

git tag --contains 2bdb76c015df7125783d8394d6339d181cb5bc30
v5.1
v5.1-rc3
v5.1-rc4
v5.1-rc5
v5.1-rc6
v5.1-rc7

summary: - 2. [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
+ [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
description: updated
description: updated

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1828495

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: eoan

List of commits needed to enable ARCH_CAPABILITIES:

Kernel:
commit 2bdb76c015df7125783d8394d6339d181cb5bc30
Author: Xiaoyao Li <email address hidden>
Date: Fri Mar 8 15:57:20 2019 +0800
    kvm/x86: Move MSR_IA32_ARCH_CAPABILITIES to array emulated_msrs

QEMU:

commit 014018e19b3c54dd1bf5072bc912ceffea40abe8
Author: Eduardo Habkost <email address hidden>
Date: Fri Jan 25 20:06:06 2019 -0200
   i386: Make arch_capabilities migratable

commit 485b1d256bcb0874bcde0223727c159b6837e6f8
Author: Eduardo Habkost <email address hidden>
Date: Fri Jan 25 20:06:05 2019 -0200
   i386: kvm: Disable arch_capabilities if MSR can't be set

commit b0a1980384fc265d91de7e09aa5fe531a69e6288
Author: Tao Xu <email address hidden>
Date: Thu Dec 27 10:43:03 2018 +0800
   i386: Update stepping of Cascadelake-Server

commit aec5e9c3a94cf8b7920f59bef69a6f426092c4a0
Author: Bandan Das <email address hidden>
Date: Sun Nov 25 23:17:28 2018 -0500
   kvm: Use KVM_GET_MSR_INDEX_LIST for MSR_IA32_ARCH_CAPABILITIES support

commit 07585923485952bf4cb7da563c9f91fecc85d09c
Author: Robert Hoo <email address hidden>
Date: Mon Oct 15 12:47:24 2018 +0800
   x86: Data structure changes to support MSR based features

commit f57bceb6ab5163ddd6c41ff4344ab8cf28a9c63d
Author: Robert Hoo <email address hidden>
Date: Mon Oct 15 12:47:23 2018 +0800
   kvm: Add support to KVM_GET_MSR_FEATURE_INDEX_LIST and KVM_GET_MSRS system ioctl

commit d86f963694df27f11b3681ffd225c9362de1b634
Author: Robert Hoo <email address hidden>
Date: Mon Oct 15 12:47:25 2018 +0800
   x86: define a new MSR based feature word – FEATURE_WORDS_ARCH_CAPABILITIES

commit c7a88b52f62b30c04158eeb07f73e3f72221b6a8
Author: Tao Xu <email address hidden>
Date: Wed Sep 19 11:11:22 2018 +0800
   i386: Add new model of Cascadelake-Server

commit 3fc7c73139d2d38ae80c3b0bc963b1ac1555924c
Author: Robert Hoo <email address hidden>
Date: Thu Jul 5 17:09:55 2018 +0800
   i386: Add CPUID bit and feature words for IA32_ARCH_CAPABILITIES MSR

commit 8a11c62da9146dd89aee98947e6bd831e65a970d
Author: Robert Hoo <email address hidden>
Date: Thu Jul 5 17:09:58 2018 +0800
   i386: Add new CPU model Icelake-{Server,Client}

commit 8c80c99fcceabd0708a5a83f08577e778c9419f5
Author: Robert Hoo <email address hidden>
Date: Thu Jul 5 17:09:54 2018 +0800
   i386: Add new MSR indices for IA32_PRED_CMD and IA32_ARCH_CAPABILITIES

Steve Beattie (sbeattie) on 2019-05-10
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in qemu (Ubuntu):
status: New → Confirmed

The top three qemu patches are in qemu 4.0 which we plan as minimum for Ubuntu 19.10.
Tagging up to be part of the Qemu work in Ubuntu 19.10.

The rest of the qemu patches is already in qemu 3.1 which is in Ubuntu 19.04

tags: added: qemu-19.10
Changed in qemu (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Wishlist
Paul Lai (pclai) wrote :

This patch is also needed for kernels before 4.18

  cd28325249 KVM: VMX: support MSR_IA32_ARCH_CAPABILITIES as a feature MSR ( 25-6-18)

This patchset populates the structure in arch/x86/kvm/x86.c:
   msr_based_features{}

With out this patch, qemu asserts at

  kvm_get_supported_feature_msrs(KVMState *s):
         assert(msr_list.nmsrs > 0);

Download full text (12.3 KiB)

WORKING

This is a comment summarising a bit the statement of work in this bug:

Bellow are the commits (and the merge requests they came from) that I
could identify by the previous comments. Judging by the selected
commits, the intent is to allow MSR supportability to be queried by
guest through CPUID MSR query emulation <-> kvm ioctls interface.
Every feature to be reported has to have its MSR declared for the CPU
type to be used AND the kvm ioctl backend + kernel support (to query
the actual hardware).

(1)

Request is to allow the following features to be reported by QEMU/KVM:

CPUID.(EAX=7H,ECX=0):EDX[26] (Enable/Disable IBRS/IBPB feature flag):

    Enumerates support for indirect branch restricted speculation
    (IBRS) and the indirect branch predictor barrier (IBPB).
    Processors that set this bit support the IA32_SPEC_CTRL MSR and
    the IA32_PRED_CMD MSR. They allow software to set
    IA32_SPEC_CTRL[0] (IBRS) and IA32_PRED_CMD[0] (IBPB).

and

CPUID.(EAX=7H,ECX=0):EDX[29] (IA32_ARCH_CAPABILITIES feature flag)

   Enumerates support for the IA32_ARCH_CAPABILITIES MSR, allowing
   MSR index 10AH to be read:

   - (bit 0) RDCL_NO: not susceptible to rogue data cache
   - (bit 1) IBRS_ALL: processor supports IBRS
   - (bit 2) RSBA: processor supports RSB alternate (retpol off)
   - (bit 3) SKIP_L1DFL_VMENTRY: vm entry don't flush L1D on VM entry
   - (bit 4) SSB_NO: processor not susceptible to spec store bypass

(2)

There is *no current request* to allow following features to be
reported by EAX_7H_ECX_0_EDX QEMU/KVM right now:

* CPUID.(EAX=7H,ECX=0):EDX[27] STIBP support flag.
* CPUID.(EAX=7H,ECX=0):EDX[28] L1D_FLUSH support flag.
* CPUID.(EAX=7H,ECX=0):EDX[31] SSBD support flag.

OBS: I haven't checked patch dependencies yet, not sure if more
patches are needed yet, just realized that SSBD support flag wasn't
being asked to be backported (nor present in 2.11 version, Bionic
version which we are targetting this to). That explains the small
"statement of work" above.

For now the request was fully understood: I'll work tomorrow in a
backport attempt to check if big pieces in between 2.11 and something
around the v3.0.0-152-g8c80c99fcc .. v4.0.0-rc0-2-g014018e19b range
are missing that would require a major refactoring that would not be
possible to be done.

(3)

Possible points of pain:

- arch_capabilities unmigratable flag inside cpu data structure
  (while CPUID was being developed) turned later on into migratable
  later.

- data structure changes to support MSR based features.

QEMU:

######## MERGE REQUEST

21ee4787e53367590f284915bf4c30c684e65bdf
174a78a8a5c0cf421236fe14efc5559717f050df
bb4928c7cafe50ab2137a0034e350ef1bfa044d9
014018e19b3c54dd1bf5072bc912ceffea40abe8 +
485b1d256bcb0874bcde0223727c159b6837e6f8 +

commit 014018e19b3c54dd1bf5072bc912ceffea40abe8 - v4.0.0-rc0-2-g014018e19b
Author: Eduardo Habkost <email address hidden>
Date: Fri Jan 25 20:06:06 2019

    i386: Make arch_capabilities migratable

    Now that kvm_arch_get_supported_cpuid() will only return
    arch_capabilities if QEMU is able to initialize the MSR properly,
    we know that the feature is safely migratable.

    Signed-off-by: Eduardo Habkost...

Sorry, last comment was posted 3 timex due to bad wrapping and mix of chars because of that. Fixed now, I've hidden 2 broken comments. Thanks

I just realized that from my previous comment I said:

(2)

There is *no current request* to allow following features to be
reported by EAX_7H_ECX_0_EDX QEMU/KVM right now:

* CPUID.(EAX=7H,ECX=0):EDX[27] STIBP support flag.
* CPUID.(EAX=7H,ECX=0):EDX[28] L1D_FLUSH support flag.
* CPUID.(EAX=7H,ECX=0):EDX[31] SSBD support flag.

But the other bug:

https://bugs.launchpad.net/intel/+bug/1830821

Is about enabling SSBD support:

CPUID.(EAX=7H,ECX=0):EDX[29] (IA32_ARCH_CAPABILITIES feature flag)
...
- (bit 4) SSB_NO: processor not susceptible to spec store bypass

and to enable guest to opt out from SSB (speculative store bypass)

Changed in qemu (Ubuntu):
status: Triaged → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → Wishlist
Changed in qemu (Ubuntu):
assignee: nobody → Rafael David Tinoco (rafaeldtinoco)
Changed in qemu (Ubuntu Disco):
status: New → Confirmed
Changed in qemu (Ubuntu Cosmic):
status: New → Confirmed
Changed in qemu (Ubuntu Bionic):
status: New → Confirmed

### For the kernel team: This QEMU patchset basically adds 2 new CPU types (IceLake and CascadeLake) support to QEMU (i386/target/{pc,kvm}) AND creates those new CPU mitigations-query features in their structure, allowing QEMU to inform guest which mitigations should be in place for the vCPUs through its own MSRs.

QEMU's

commit f57bceb6ab5163ddd6c41ff4344ab8cf28a9c63d
Author: Robert Hoo <email address hidden>
Date: Mon Oct 15 04:47:23 2018

    kvm: Add support to KVM_GET_MSR_FEATURE_INDEX_LIST and KVM_GET_MSRS system ioctl

    Add kvm_get_supported_feature_msrs() to get supported MSR feature index list.
    Add kvm_arch_get_supported_msr_feature() to get each MSR features value.

    Signed-off-by: Robert Hoo <email address hidden>
    Message-Id: <email address hidden>
    Reviewed-by: Eduardo Habkost <email address hidden>
    Signed-off-by: Eduardo Habkost <email address hidden>

Summarizes the kernel support we need for this "RFE" on Bionic (and higher) QEMUs.

Basically we need support for our ioctl() calls being added here:

kvm_ioctl(s, KVM_GET_MSRS, &msr_data);

kvm_ioctl(s, KVM_GET_MSR_FEATURE_INDEX_LIST, &msr_list);

to be backported to Bionic (and HWE in Bionic) kernels.

With this support, QEMU will be able to query IA32_ARCH_CAPABILITIES MSRs.

More information to this feature can be found:

http://kib.kiev.ua/x86docs/SDMs/336996-002.pdf

Chapter 5 (5.1 - Enumeration by CPUID).

Previous chapters describe briefly the vulnerabilities and how mitigations work HW wise.

Rafael - Is this completed for Bionic releases?
Thank you

Hi pragyansri,
If you track the progress on the merge proposal that is linked this looks good atm and will soon be in a PPA [2] with proposed changes for pre-evaluation with Bionic/Cosmic/Disco/Eoan.

From there the next steps are:
- test the new feature from the PPA on cascade lake machines
- general regression tests
- Once we know it works (Tests on newer kernels) will need to also involve the kernel Team to also backport the kernel patches
- if the above look good as well it will become an SRU [1]
- The SRU processing will have it reviewed by the SRU Team, then land in proposed to be final verified and then be released to be available

Sorry if that seems slow to you, but the changes are complex and we don't want to rush things - if you read the SRU [1] policy you'll see that the steady tradeoff of stability-vs-fixes is important to be done with the focus of avoiding regressions.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates
[2]: https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA

description: updated

Alright, so we are still testing the version we're working on but here are some test results...

The merge request can be found here:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/368804
with code reviews and comments in between the backport attempts.

PPA containing a test version can be found here:
https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1828495

And the HOST and GUEST kernels were: Linux XXX 4.18.0-23-generic #24~18.04.1-Ubuntu SMP Thu Jun 13 17:08:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

since the regular bionic kernel has to have support backported.

I have tested for the MITIGATIONS in:

1) HOST (Bionic)

2) OLD QEMU GUEST (Bionic)

3) NEW QEMU (w/ backport) GUEST (Bionic)

And will show the results:

Download full text (8.3 KiB)

1) HOST (Bionic)

#### CASCADE LAKE HOST INFORMATION:

Spectre and Meltdown mitigation detection tool v0.42-1-g91d0699

Checking for vulnerabilities on current system Kernel is Linux
4.18.0-23-generic #24~18.04.1-Ubuntu SMP Thu Jun 13 17:08:52 UTC 2019 x86_64
CPU is Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz

--------

Hardware check

* Hardware support (CPU microcode) for mitigation techniques

  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available: YES
    * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates STIBP capability: YES (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability: YES (Intel SSBD)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available: YES
    * CPU indicates L1D flush capability: YES (L1D flush feature bit)
  * Microarchitecture Data Sampling
    * VERW instruction is available: YES (MD_CLEAR feature bit)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability: YES
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: YES
  * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): YES
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system: YES
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDS_NO): YES
  * CPU supports Software Guard Extensions (SGX): NO
  * CPU microcode is known to cause stability problems: NO (model 0x55 family 0x6 stepping 0x6 ucode 0x4000021 cpuid 0x50656)
  * CPU microcode is the latest known available version: NO (latest version is 0x4000024 dated 2019/04/07 according to builtin MCExtractor DB v112 - 2019/05/22)

--------

* CPU vulnerability to the speculative execution attack variants

  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection): YES
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): NO
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): YES
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass): YES
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): NO
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): NO
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): NO
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): NO
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): NO
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitect...

Read more...

Download full text (9.9 KiB)

2) OLD QEMU GUEST (Bionic)

#### REGULAR QEMU GUEST IN OLD QEMU

Spectre and Meltdown mitigation detection tool v0.42-1-g91d0699

Checking for vulnerabilities on current system Kernel is Linux
4.18.0-23-generic #24~18.04.1-Ubuntu SMP Thu Jun 13 17:08:52 UTC 2019 x86_64
CPU is Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz

--------

Hardware check

* Hardware support (CPU microcode) for mitigation techniques

  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available: YES
    * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates STIBP capability: NO
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability: YES (Intel SSBD)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available: NO
    * CPU indicates L1D flush capability: NO
  * Microarchitecture Data Sampling
    * VERW instruction is available: YES (MD_CLEAR feature bit)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability: NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
  * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): NO
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDS_NO): NO
  * CPU supports Software Guard Extensions (SGX): NO
  * CPU microcode is known to cause stability problems: NO (model 0x55 family 0x6 stepping 0x6 ucode 0x1 cpuid 0x50656)
  * CPU microcode is the latest known available version: NO (latest version is 0x4000024 dated 2019/04/07 according to builtin MCExtractor DB v112 - 2019/05/22)

--------

* CPU vulnerability to the speculative execution attack variants

  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection): YES
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): YES
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): YES
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass): YES
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): YES
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): YES
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): YES
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): YES
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): YES
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)): YE...

Download full text (11.5 KiB)

3) NEW QEMU (w/ backport) GUEST: Bionic

#### REGULAR QEMU GUEST IN NEW QEMU

Spectre and Meltdown mitigation detection tool v0.42-1-g91d0699

Checking for vulnerabilities on current system Kernel is Linux
4.18.0-23-generic #24~18.04.1-Ubuntu SMP Thu Jun 13 17:08:52 UTC 2019 x86_64
CPU is Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz

-------

Hardware check

* Hardware support (CPU microcode) for mitigation techniques

  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available: YES
    * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available: YES
    * CPU indicates STIBP capability: NO
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability: YES (Intel SSBD)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available: NO
    * CPU indicates L1D flush capability: NO
  * Microarchitecture Data Sampling
    * VERW instruction is available: YES (MD_CLEAR feature bit)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability: YES
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: YES
  * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): YES
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system: YES
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDS_NO): NO
  * CPU supports Software Guard Extensions (SGX): NO
  * CPU microcode is known to cause stability problems: NO (model 0x55 family 0x6 stepping 0x6 ucode 0x1 cpuid 0x50656)
  * CPU microcode is the latest known available version: NO (latest version is 0x4000024 dated 2019/04/07 according to builtin MCExtractor DB v112 - 2019/05/22)

--------

* CPU vulnerability to the speculative execution attack variants

  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection): YES
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): NO
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): YES
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass): YES
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): NO
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): NO
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): YES
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): YES
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): YES
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory ...

Download full text (4.7 KiB)

*) SUMMARY:

In between the old and new QEMU, changed results for the mitigations checker was:

#### DIFF between old QEMU and this new one

Hardware check

* Hardware support (CPU microcode) for mitigation techniques

  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability: YES
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: YES

  * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): YES

  * CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO

--------

* CPU vulnerability to the speculative execution attack variants

  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): NO
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): NO
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): NO

--------

## CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'

OLD QEMU:

* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support: YES
    * IBRS enabled and active: YES (for firmware code only)
  * Kernel is compiled with IBPB support: YES
    * IBPB enabled and active: YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm): NO
  * Kernel compiled with retpoline option: YES
    * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
  * Kernel supports RSB filling: YES

> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)

NEW QEMU:

* Mitigated according to the /sys interface: YES (Mitigation: Enhanced IBRS, IBPB: conditional, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support: YES
    * IBRS enabled and active: YES
  * Kernel is compiled with IBPB support: YES
    * IBPB enabled and active: YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm): NO
  * Kernel compiled with retpoline option: YES
  * Kernel supports RSB filling: YES

> STATUS: NOT VULNERABLE (IBRS + IBPB are mitigating the vulnerability)

--

## CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'

OLD QEMU:

* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
  * PTI enabled and active: YES
  * Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU: NO

> STATUS: NOT VULNERABLE (Mitigation: PTI)

NEW QEMU:

* Mitigated according to the /sys interface: YES (Not affected)
* Kernel supports Page Table Isolation (PTI): YES
  * PTI enabled and active: NO
  * Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU: NO

> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

--

OLD QEMU:

## CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'

* Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT ...

Read more...

TL;DR:

HOST MITIGATION FEATURES REPORT:
https://bugs.launchpad.net/intel/+bug/1828495/comments/15

OLD QEMU GUEST MIT FEATURES REPORT:
https://bugs.launchpad.net/intel/+bug/1828495/comments/16

NEW QEMU GUEST MIT FEATURES REPORT:
https://bugs.launchpad.net/intel/+bug/1828495/comments/17

MIT FEATURES REPORT DELTA FROM OLD TO NEW:
https://bugs.launchpad.net/intel/+bug/1828495/comments/18

Meaning we basically have enabled INSIDE the GUEST:

* Hardware support (CPU microcode) for mitigation techniques

  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability: YES
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: YES
  * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): YES
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO

and

* CPU vulnerability to the speculative execution attack variants

  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): NO
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): NO
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): NO

@rafaeldtinoco: I found some forther more ugly detail for the stepping change from 5 to 6.
Qemu 3.1 as in Disco had Cascade lake with the stepping 5.
So for Disco the SRU will change the definition.
Which is different to Bionic/Cosmic where we can say "our Cascade definition will just always have been 6" since it didn't exist before the SRU

You'll spot that when you start to create the branch for disco
Note: cosmic has none of the types

Due to that for those users who have set up guests to use "Cascadelake-Server" the SRU on Disco (or the respective cloud archive) will make them need to restart the guest before they can migrate it to a system with the updates applied.

For bionic/cosmic users things will be fine as they have nothing->stepping6
And Eoan will be released with stepping 6

I think that is a drawback, but a tradeoff that we will have to make for the overall gain for much more users. But we need to declare that in the regression considerations of the bug when pushing the SRU.

@rafaeldtinoco: when you have branches and PPAs for Disco as well, could you spawn a Cascadelake-Server guest on a node without the upgrade and then migrate to a note with the upgrade?
I expect an issue, but we should know how exactly it looks.
Once we do we will add that to the SRU template in the description.

This also affects "Cascadelake-Server" defined guests migrating from patched Bionic to unpatched Disco - that will fail. But requiring updates being applied is fine, only the enforced guest restart (which doesn't apply to the just mentioned use-case) is the thing that is really bad.

Overall maybe even worth a NEWS entry for the Disco upload to increase the chance of admins being aware. Please add one on the Disco branch for this.

Download full text (7.8 KiB)

Alright. I had in mind that (for bionic/cosmic) but we definitely have to mention what you said (for started guests). About the migration, will cause the issue and report back after cosmic/disco backport.

About needed CPU features. I could get the following... these are the needed cpuflags to have a good mitigation status (and opt out from some heavy workarounds/mitigations inside guest):

arch_capabilities=on
ssbd=on
md-clear=on,
wbnoinvd=off
bpb=off
virt-ssbd=off
rdctl-no=yes
ibrs-all=yes
rsba=yes
skip-l1dfl-vmentry=yes
ssb-no=yes

As we've discussed, I backported EOAN's libvirt 5.4.0-0ubuntu2 to Bionic and checked support...

This is the difference when starting CPU as passthrough and CPU as CascadeLake:

$ diff -y one two | grep -E "(>|<)"
arch_capabilities <
arch_perfmon <
ept <
flexpriority <
ibrs_enhanced <
md_clear <
                                                              > pti
ss <
tpr_shadow <
tsc_adjust <
umip <
vmx <
vnmi <
vpid <
xsaves <
xtopology <

As you can see we have to enable the CPU features in order to fully inform guest about HW mitigations and such. Going a bit deeper:

INTEL:

arch-capabilities
invpcid

  <cpu mode='custom' match='exact' check='partial'>
    <model fallback='allow'>Cascadelake-Server</model>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='invpcid'/>
  </cpu>

AMD ONLY:

wbnoinvd
ibpb
virt-ssbd

saw support in libvirt XML files.

COULD NOT FIND specific support for the following CPU features:

ssbd
md-clear
bpb
ibrs-all
rdctl-no
rsba
skip-l1dfl-vmentry

I guess that we will have to backport this support in libvirt, in order to allow QEMU to pick specific CPU mitigation flags.

----

This is the difference from executing QEMU with passthrough versus specifying the Cascadelake Server WITHOUT picking up specific flags (as they are unsupported):

----

HOST has MD_CLEAR, CPU type not:

    * VERW instruction is available: YES (MD_CLEAR feature bit)

HOST has arch_capabilities, CPU type not:

    * CPU indicates ARCH_CAPABILITIES MSR availability: YES
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: YES

 * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): YES

 * CPU/Hypervisor indicates L1D flushing is not necessary on this system: YES

HOST reports not being vulnerable to:

  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, r...

Read more...

> ssbd
> md-clear
> bpb
> ibrs-all
> rdctl-no
> rsba
> skip-l1dfl-vmentry
>
> I guess that we will have to backport this support in libvirt, in order
> to allow QEMU to pick specific CPU mitigation flags.

Those are not all missing at least. I have seen ssbd and md-clear for
sure in Bionic e.g. for the latter coming with
ubuntu/bionic-4.0:debian/patches/md-clear.patch

In the context of this bug we will take a look at arch_capabilities
and if some of the others are low hanging fruits.
Quite often - but not always - for libvirt it is just a CPU bit
definition, but as we know e.g. arch_cap is more complex.

@rafael - One more question about Stepping 5/6.
I have formerly read your explanation that stepping 6 would be
required to be able to enable arch_capabilities.
And we planned to add all SRUs with stepping 6 right away and keep the
Delta to consider all versions to be stepping 6.

But then I have seen [1] and in particular [2].
Overall this adds more complexity but also more ability to CPU model
definitions.
But in between the lines in [2] I read that arch_capabilities gets
enabled by default and stepping goes back to 5.

That seems to imply that enabling it on stepping 5 isn't an issue.

If it does work doing the SRU that way it will ease maintenance in the future.
Especially since these versioned types will make maintaining Delta in
that area even more complex.
And it would avoid the upgrade issue on Disco where the CascadeLake
would change.

Therefore I wondered if we could make the backport use stepping 5
which would allow to not carry the delta forever in >=Eoan.
Could you make a PPA build as it is right now, but with stepping 5 and
check if using arch_capabilities still works for you?

[1]: https://<email address hidden>/msg626545.html
[2]: https://<email address hidden>/msg626550.html

Changed in qemu (Ubuntu Eoan):
status: Confirmed → In Progress
Changed in linux (Ubuntu Eoan):
status: Confirmed → In Progress
Changed in qemu (Ubuntu Disco):
assignee: nobody → Rafael David Tinoco (rafaeldtinoco)
Changed in qemu (Ubuntu Cosmic):
assignee: nobody → Rafael David Tinoco (rafaeldtinoco)
Changed in qemu (Ubuntu Bionic):
assignee: nobody → Rafael David Tinoco (rafaeldtinoco)
Changed in qemu (Ubuntu Disco):
importance: Undecided → Wishlist
Changed in qemu (Ubuntu Cosmic):
importance: Undecided → Wishlist
Changed in qemu (Ubuntu Bionic):
importance: Undecided → Wishlist
Changed in linux (Ubuntu Disco):
importance: Undecided → Wishlist
status: New → Confirmed
Changed in linux (Ubuntu Cosmic):
importance: Undecided → Wishlist
status: New → Confirmed
Changed in linux (Ubuntu Bionic):
importance: Undecided → Wishlist
status: New → Confirmed
Download full text (3.5 KiB)

https://<email address hidden>/msg626552.html

On the first patch of the set, Eduardo says:

"""
The last patch in the series demonstrates how the new feature can
be used to update a CPU model: it adds a Cascadelake-Server-4.1.1
CPU model, including "arch-capabilities=on" and "stepping=5".
Unfortunately we can't enable arch-capabilities in the -4.1
version of Cascadelake-Server because it would break our existing
runnability guarantees.
"""

He likely discovered partial support for the mitigations on CPUs
with stepping=5 and wanted to implement arch_capabilities in order
to report those back to guests.

From:

https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake

we have:

"""
Hardware mitigations for:

CVE-2017-5715 - Spectre (Variant 2)
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

CVE-2017-5754 - Meltdown (Variant 3)
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)

CVE-2018-3640 - RSRE - Rogue System Register Read (Variant 3a)
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#V3a

CVE-2018-{3620,3646} - Foreshadow (L1 Terminal Fault) VMs,VMM,OS,SMM
https://en.wikipedia.org/wiki/Foreshadow_(security_vulnerability)

*MDS* (Microarchitectural Data Sampling) attacks:
(MDS; MFBDS, RIDL, MSBDS, Fallout, MLPDS, MDSUM)
https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampling

RIDL types:

1. (CVE-2018-12127) - MLPDS - Microarchitectural Load Port Data Sampling
2. (CVE-2018-12130) - MFBDS - Microarchitectural Fill Buffer Data Sampling
3. (CVE-2019-11091) - MDSUM - Microarchitectural Data Sampling Uncacheable Memory

https://mdsattacks.com/files/ridl.pdf

ZombieLoad type:

2. (CVE-2018-12130) - MFBDS - Microarchitectural Fill Buffer Data Sampling

Fallout type:

4. (CVE-2018-12126) - MSBDS - Microarchitectural StoreBuffer Data Sampling

https://mdsattacks.com/files/fallout.pdf

*** NOTE ***

- Steppings 6 and 7 are fully mitigated

- Stepping 5 is NOT PROTECTED against:

  a. MSBDS - (Faulout) Microarchitectural StoreBuffer Data Sampling
  b. MLPDS - (RIDL) Microarchitectural Load Port Data Sampling
  c. MDSUM - (RIDL) Microarchitectural Data Sampling Uncacheable Memory
"""

Commit 6/6 shows:

"""
The new feature will introduce a new host software requirement,
breaking our CPU model runnability promises. This means we can't
enable the new CPU model version by default in QEMU 4.1, because
management software isn't ready yet to resolve CPU model aliases.
This is why the feature is being enabled in a
Cascadelake-Server-4.1.1 CPU model instead of
Cascadelake-Server-4.1.
"""

Based on status on that discussion, unfinished and untested work, and
the fact that we're backporting things, and after our hangout, it is
clear the need to stay with stepping=5 in order to better maintain
qemu in Bionic/Cosmic/Disco, but, like we discussed, informing end
user about how to enable proper CPU flags to advertise HW mitigations
to the GUEST using specific cpu flags (QEMU and libvirt support):

+arch_capabilities (together with, or not):
    +rdctl-no
    +ibrs-all
    +rsba
    +skip-l1dfl-vmentry
    +ssb-no
+ssbd
+md-clear

just like you did in:

https://wiki.ubuntu.com/Security...

Read more...

Changed in qemu (Ubuntu Disco):
status: Confirmed → In Progress
Changed in qemu (Ubuntu Cosmic):
status: Confirmed → In Progress
Changed in qemu (Ubuntu Eoan):
assignee: Rafael David Tinoco (rafaeldtinoco) → Christian Ehrhardt  (paelzer)
Changed in qemu (Ubuntu Bionic):
status: Confirmed → In Progress
quanxian (quanxian-wang) wrote :

we have verified that on 18.04.2 with Rafael David Tinoco (rafaeldtinoco)'s PPA qemy packages. And get that guest doesn't work as expected. After detailed discussion with Intel Upstream, there still needs some patches. But they are under review. Keep watch the process of process.

https://<email address hidden>/msg627282.html

Hello quanxian,

Could you clarify exactly what is the expected behaviour and what wasn't achieved ?
We'd like to understand better the requirements, rather than having patches pointed out only. Mainly because there are some rules we usually follow for already released versions and some of them might be discussable and some might not.

Based on the thread you pointed out:

----
* Patch "i386: Infrastructure for versioned CPU models" was
  rewritten and split in two:
  * i386: Register versioned CPU models
  * i386: Make unversioned CPU models be aliases
* -IBRS, -noTSX, -IBPB CPU models are now aliases
* Enable rdctl-no, ibrs-all, skip-l1dfl-vmentry in
  Cascadelake-Server-v2
* New patch added:
  * i386: Get model-id from CPU object on "-cpu help"
----

Are you looking for the CPU versioning feature ? (Rather than only having stepping increased/decreased ?). Are you looking for Cascadelake-server-v2 CPU type ? Or on having, by default, the CPU flags rdctl-no, ibrs-all, skip-l1dfl-vmentry enabled ?

I'm asking you this because, for backports, we are looking forward to enabling those features ad-hoc, and not by default (as they seem to be in the PPA). Specially because we have to guarantee compatibility in between QEMU diff versions migrations. This has been done already before, for some other requested features.

Thank you very much in advance for your feedback.

quanxian (quanxian-wang) wrote :

Expected results is:
HOST and Guest should enable IA32_ARCH_CAPABILITIES MSR.
MDS_NO is bit 5 of ARCH_CAPABILITIES. Expose this bit to guest.

##cpuid -r
0x00000007 0x00: eax=0x00000000 ebx=0xd19f4fb9 ecx=0x00000818 edx=0x84000000
edx's 29 bit should be 1.

#rdmsr 0x10a -f 5:5
return value should be 1

Actual result is
host works well as expected.
guest not.

Below are details.

Host
# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=ubuntu-18.04.2-server-amd64.qcow,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server,+arch-capabilities -serial stdio -redir tcp:2223::22

root@PLY02:~# cpuid -r |more
CPU 0:
   0x00000000 0x00: eax=0x00000016 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69
……
   0x00000007 0x00: eax=0x00000000 ebx=0xd39ffffb ecx=0x00000818 edx=0xbc000400

edx is 0xbc000400, 29bit is 1

root@PLY02:~# rdmsr 0x10AH
2b

## 5 bit is 1

Guest

root@test:~# cpuid -r |more
CPU 0:
   0x00000000 0x00: eax=0x0000000d ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69
   ……
   0x00000007 0x00: eax=0x00000000 ebx=0xd19f4fb9 ecx=0x00000818 edx=0x84000000

## edx's 29 bit is 0

root@PLY02:~# rdmsr 0x10AH
0
## 5 bit is 0

Reason:
If you want to see the features that enumerated by MSR_IA32_ARCH_CAPABILITIES in guest with Cascadelake-Server cpu model, just using “-cpu Cascadelake-Server,+arch-capabilities” is not enough.
“-cpu Cascadelake-Server,+arch-capabilities” only let guest see MSR_IA32_ARCH_CAPABILITIES, but it doesn’t contain any feature enumerated by this msr, so the result of rdmsr 0x10a is 0.

If you want to see feature MDS_NO (bit 5) in guest, you should use “-cpu Cascadelake-Server,+arch-capabilities,+mds_no”.

Further, we get 0x2b (bit 0,1,3,5) when rdmsr 0x10a in host, which means host supports “rdctl-no”, “ibrs-all”, “skip-l1dfl-vmentry”, "mds-no".
If we want guest has the same ability as host, not only should we add arch_capabilities explicitly, but also add the features list above explicitly. Otherwise we cannot see these features in guest.

In a word, it’s all due to current Cascadelake-Server cpu model. It lacks all above.
After new version of Cascadelake-Server added in qemu, we can get rid of all these manually adding features annoyance.

Eduardo has sent out the qemu patch for versioned cpu model and patch 09 of which contains new version of Cascadelake Server cpu model. It depends on when they are merged.
https://<email address hidden>/msg627282.html

The series was merged in 3a1acf5d47295d22ffdae0982a2fd808b802a7da as a prep to qemu 4.1.
But the changes are rather invasive and after a review I think for the SRU we will not add them.

For example the changes around:
  "model runnability guarantees won't apply to unversioned CPU models anymore"
seems non backportable to me.
I agree it is the right path going forward to keep the proliferation of CPU models under control and provide something like a "moving head" weakening the runability guarantees that can be regained by fetching the exact versions via alias-of.

But none of the old systems management stacks will be able to do so.
Yes there is [2] but I'm still scared in an SRU context to add that when it is a valid (more effort but working) option to add model+flags for the time being.

And in addition the code for making the models versionable will be another great set of backports with potential backport flaws added.

Hence at least for now my decision would be:
- make the features available at least to the last LTS (Bionic) which will reach
  LTS-1 for many (to admit not all) users via Ubuntu cloud archive
- do not backport the versioned CPU model changes (too much risk / incompatibilities)
  - pro: no changes to the higher virt stack needed
  - pro: less regression risk for the SRUs
  - pro: the new security features will be available
  - con: security features must be enabled individually via feature flags

@Rafael that should match what you had prepared in your MPs already.
I'll create a PPA with your any my changes for general regression tests.

@Quaxlan - for the versioned CPUs an all that belongs to that context I'd ask you to file a new bug. I expect that will be in qemu 4.1 (just entered rc0) and a later (yet to be defined) libvirt version. Once all of that has properly landed we can consider if we will pull it back into Eoan (as long as it isn't released and under the SRU policy) OR if we wait for these new features to properly arrive in the next Ubuntu release being 20.04. Once you happen to know which libvirt version will have the appropriate changes to properly tolerate and exploit what was added to qemu via [1] (version and commits if you have both) let us know there.

[1]: https://<email address hidden>/msg627282.html
[2]: https://<email address hidden>/msg628326.html

And qemu 4.0 is in Eoan, so this release is "fix released" (for the scope of adding the features, not the just discussed versioned CPUs)

Changed in qemu (Ubuntu Eoan):
status: In Progress → Fix Released
assignee: Christian Ehrhardt  (paelzer) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers