RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1709857 - RFE - Ability to add IBPB feature policy to mitigate Spectre v2 for VM guests
Summary: RFE - Ability to add IBPB feature policy to mitigate Spectre v2 for VM guests
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virt-manager
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 8.0
Assignee: Pavel Hrdina
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1716402
TreeView+ depends on / blocked
 
Reported: 2019-05-14 12:33 UTC by Pavel Hrdina
Modified: 2020-11-14 09:02 UTC (History)
7 users (show)

Fixed In Version: virt-manager-2.2.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1716402 (view as bug list)
Environment:
Last Closed: 2019-11-05 21:20:21 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3464 0 None None None 2019-11-05 21:20:37 UTC

Description Pavel Hrdina 2019-05-14 12:33:11 UTC 
This bug was initially created as a copy of Bug #1582667

I am copying this bug because: 



Description of problem:

There is no way to add feature policy to CPU type, in order for Opteron CPU's to mitigate Spectre vulnerabilities, the following feature policy must be enabled for Opteron CPU's. [1]

   <cpu mode='custom' match='exact'>
      <model fallback='forbid'>Opteron_G5</model>
      <feature policy='require' name='ibpb'/>
    </cpu>

Version-Release number of selected component (if applicable):


How reproducible:

100% 

Steps to Reproduce:
1. Create a new VM on a RHEL host using an Opteron G4/5 CPU via virt-manager
2. Ensure vendor provided patches for CVE-2017-5715 are applied to the host
3. Test guest VM which is not patched for Spectre v2

Actual results:

Guest VM is vulnerable to Spectre v2

Expected results:

VM should not be vulnerable. Add ability to specify this in virt-manager or inherit the proper mitigation if the host microcode has been updated. Also provide a method to make changes to existing VM's so they do not need to be edited with virsh.


Additional info:


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1582582#c3
Comment 1 Daniel Berrangé 2019-05-14 19:19:21 UTC 
Must also include the new md-clear feature https://www.redhat.com/archives/virt-tools-list/2019-May/msg00019.html
Comment 3 Pavel Hrdina 2019-05-20 20:07:44 UTC 
Moving back to assigned as the virt-install secure=no option is not working.
Comment 8 zhoujunqin 2019-08-02 09:09:58 UTC 
Try to verify this bug with new build:

virt-install-2.2.1-1.el8.noarch
virt-manager-2.2.1-1.el8.noarch
libvirt-4.5.0-31.module+el8.1.0+3808+3325c1a3.x86_64
qemu-kvm-2.12.0-82.module+el8.1.0+3738+0d8c0249.x86_64

Steps:
1. Prepare a host which support ibpb(there is IBRS or IBPB keyword in cpu model):  

# virsh capabilities
<capabilities>

  <host>
    <uuid>b2395aee-86ef-323a-ed97-3a5e0c2b3a8a</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Nehalem-IBRS</model>
      <vendor>Intel</vendor>
...

Scenario-1 Testing on virt-manager UI

1. Launch virt-manager
# virt-manager

2. Set 'Edit'->'Preferences'->'New VM defaults'->select 'CPU default' as 'Copy host CPU definition', then click 'Close'.

3. Install a vm.
3.1 Select the local connection: QEMU/KVM
3.2 Click NEW button at the top of Virtual Machine Manager dialogue.
3.3 Select "Import existing disk image", and Click "Forward" button.
3.4 Enter an existing disk path
3.5 Check "Automatically detect operating system based on install media", then click 'Forward'.
3.6 Keep following pages as default setting, and click 'Forward' step by step until click "Finish" button.
Result: Installation finishes with no error.

4. Check "new checkbox to control CPU security features" works. 
Double click a VM, and turn to "Show virtual hardware details" page.
Result: 
4.1 Cpu Model shows "SandyBridge-IBRS".
4.2 New checkbox "Enable available CPU security flaw mitigations" is added and it is checked by default.
# virsh dumpxml $guest
...
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>SandyBridge-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='arat'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='umip'/>
    <feature policy='require' name='md-clear'/>
    <feature policy='require' name='stibp'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='xsaveopt'/>
    <feature policy='disable' name='aes'/>
  </cpu>

4.2.1 Login guest and check guest cpu feature have ibpb
# cat /proc/cpuinfo

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx hypervisor lahf_lm ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust xsaveopt arat umip spec_ctrl intel_stibp arch_capabilities


Result: CPU security features(spec_ctrl,ssbd, ibpb) are added.

As a summary, it works well on virt-manager UI.

Scenario-2 Testing with virt-install cml.
1. Enable CPU secure parameter
# virt-install --name cpu --memory 1024 --disk /var/lib/libvirt/images/spice.qcow2  --import --cpu secure=yes --noautoconsole 
...
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>SandyBridge-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='arat'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='umip'/>
    <feature policy='require' name='md-clear'/>
    <feature policy='require' name='stibp'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='xsaveopt'/>
    <feature policy='disable' name='aes'/>
  </cpu>

Result: CPU security features are enabled with "secure=yes" setting

2. Disable CPU secure parameter
# virt-install --name cpu --memory 1024 --disk /var/lib/libvirt/images/spice.qcow2  --import --cpu secure=no --noautoconsole 
...
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>SandyBridge-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='arat'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='umip'/>
    <feature policy='require' name='md-clear'/>
    <feature policy='require' name='stibp'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='xsaveopt'/>
    <feature policy='disable' name='aes'/>
  </cpu>

Result: Get same result with "secure=yes" setting.

Hi Pavel, please help me have a look, it seems 'secure=no' doesn't work well, thanks.
Comment 9 Pavel Hrdina 2019-08-19 12:20:27 UTC 
Hi Junqin,

In the case of this command:

virt-install --name cpu --memory 1024 --disk /var/lib/libvirt/images/spice.qcow2  --import --cpu secure=no --noautoconsole

The secure will not affect anything.  It's stated in man page that "secure" is used only together with exact CPU models.
The command that you are using will create this XML:

<domain type="kvm">
  ...
  <cpu mode="host-model"/>
  ...
</domain>

and libvirt expands the host-model when the VM is started.
Comment 10 zhoujunqin 2019-08-22 08:05:18 UTC 
Hi Pavel,
Thanks for your detail explanation, i understand it now, i should use "--cpu model=EPYC-IBPB,secure=no" for testing secure suboption.
I loan an AMD machine for testing, to ensure the result quality, thanks. 

Verify with packages:
virt-manager-2.2.1-2.el8.noarch
virt-install-2.2.1-2.el8.noarch
libvirt-4.5.0-32.module+el8.1.0+4005+3cd7764e.x86_64
qemu-kvm-2.12.0-84.module+el8.1.0+4005+3cd7764e.x86_64

Steps:
1. Prepare a host which support ibpb(there is IBRS or IBPB keyword in cpu model):  

# virsh capabilities
<capabilities>

  <host>
    <uuid>4c4c4544-0035-5910-8059-b4c04f4c4e32</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>EPYC-IBPB</model>
      <vendor>AMD</vendor>
      <microcode version='134222375'/>
...

Scenario-1 Testing on virt-manager UI

1. Launch virt-manager
# virt-manager

2. Set 'Edit'->'Preferences'->'New VM defaults'->select 'CPU default' as 'Copy host CPU definition', then click 'Close'.

3. Install a vm.
3.1 Select the local connection: QEMU/KVM
3.2 Click NEW button at the top of Virtual Machine Manager dialogue.
3.3 Select "Import existing disk image", and Click "Forward" button.
3.4 Enter an existing disk path
3.5 Check "Automatically detect operating system based on install media", then click 'Forward'.
3.6 Keep following pages as default setting, and click 'Forward' step by step until click "Finish" button.
Result: Installation finishes with no error.

4. Check "new checkbox to control CPU security features" works. 
Double click a VM, and turn to "Show virtual hardware details" page.
Result: 
4.1 Cpu Model shows "EPYC-IBPB".
4.2 New checkbox "Enable available CPU security flaw mitigations" is added and it is checked by default.
# virsh dumpxml $guest
...
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-IBPB</model>
    <vendor>AMD</vendor>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='tsc-deadline'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='cmp_legacy'/>
    <feature policy='require' name='perfctr_core'/>
    <feature policy='require' name='virt-ssbd'/>
    <feature policy='disable' name='monitor'/>
    <feature policy='disable' name='svm'/>
    <feature policy='require' name='topoext'/>
  </cpu>

4.2.1 Login guest and check guest cpu feature have ibpb
#lscpu

Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl xtopology cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 virt_ssbd arat arch_capabilities


Result: CPU security features(ssbd, ibpb, virt_ssbd) are added.

As a summary, it works well on virt-manager UI.

Scenario-2 Testing with virt-install.

1. Enable CPU secure parameter

1.1 From virt-install man page, the value for secure is on as the default.

# man virt-install
       --cpu MODEL[,+feature][,-feature][,match=MATCH][,vendor=VENDOR],...
           Configure the CPU model and CPU features exposed to the guest. The only required value is MODEL, which is a valid CPU model as known to libvirt.

           Libvirt's feature policy values force, require, optional, disable, or forbid, or with the shorthand '+feature' and '-feature', which equal 'force=feature' and 'disable=feature' respectively.

           If exact CPU model is specified virt-install will automatically copy CPU features available on the host to mitigate recent CPU speculative execution side channel and Microarchitectural Store
           Buffer Data security vulnerabilities.  This however will have some impact on performance and will break migration to hosts without security patches. In order to control this behavior there is a
           secure parameter. Possible values are on and off, with on as the default. It is highly recommended to leave this enabled and ensure all virtualization hosts have fully up to date microcode,
           kernel & virtualization software installed.

# virt-install --name sec-default --memory 2048 --disk /var/lib/libvirt/images/foo.qcow2  --import --cpu model=EPYC-IBPB --noautoconsole

# virsh dumpxml sec-default 
...
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-IBPB</model>
    <feature policy='require' name='ibpb'/>
    <feature policy='require' name='virt-ssbd'/>
    <feature policy='disable' name='monitor'/>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='disable' name='svm'/>
    <feature policy='require' name='topoext'/>
  </cpu>

Result: CPU security features are enabled by default.

1.2 Testing with "secure=yes"

# virt-install --name sec-enable --memory 2048 --disk /var/lib/libvirt/images/foo.qcow2  --import --cpu model=EPYC-IBPB,secure=yes --noautoconsole


# virsh dumpxml sec-enable
...
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-IBPB</model>
    <feature policy='require' name='ibpb'/>
    <feature policy='require' name='virt-ssbd'/>
    <feature policy='disable' name='monitor'/>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='disable' name='svm'/>
    <feature policy='require' name='topoext'/>
  </cpu>

Result: CPU security features are enabled with "secure=yes" setting

2. Disable CPU secure parameter
# virt-install --name sec-disable --memory 2048 --disk /var/lib/libvirt/images/foo.qcow2  --import --cpu model=EPYC-IBPB,secure=no --noautoconsole

# virsh dumpxml sec-disable
...
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-IBPB</model>
    <feature policy='disable' name='monitor'/>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='disable' name='svm'/>
    <feature policy='require' name='topoext'/>
  </cpu>

Result: CPU security features are disabled with "secure=no" setting.

So I move this bug from ON_QA to VERIFIED based on above testing.
Comment 12 errata-xmlrpc 2019-11-05 21:20:21 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3464
Note You need to log in before you can comment on or make changes to this bug.