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 1582582 - No IBPB CPU type for Opteron processors to mitigate Spectre v2 for VM
Summary: No IBPB CPU type for Opteron processors to mitigate Spectre v2 for VM
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5
Hardware: x86_64
OS: Unspecified
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-25 16:05 UTC by amashah
Modified: 2023-03-24 14:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1582613 (view as bug list)
Environment:
Last Closed: 2018-05-25 18:44:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1582613 0 high CLOSED [RHV] No IBPB CPU type for Opteron processors to mitigate Spectre v2 for VM 2023-09-18 00:13:42 UTC
Red Hat Bugzilla 1582667 0 high CLOSED RFE - Ability to add IBPB feature policy to mitigate Spectre v2 for VM guests 2023-03-24 14:05:55 UTC
Red Hat Knowledge Base (Solution) 3460201 0 None None None 2018-05-25 16:31:03 UTC

Internal Links: 1582613 1582667

Description amashah 2018-05-25 16:05:29 UTC
Description of problem:

No IBPB CPU type for Opteron processors to mitigate Spectre for virtual machines


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

7.5


Actual results:

There appears to be no IBPB CPU type to select from in Virtual Machine Manager (or elsewhere) for Opteron processors to allow for the IBPB Spectre mitigations to be passed from the host machine to the virtual guests running on the host machine. There is an option for IBPB EPYC and IBRS options for all the Intel processors, but nothing for Opteron [1].

Official BIOS updates from Dell for PowerEdge R815 systems were applied (which are still supported by Red Hat for RHEL 7) that we use as virtual host machines using KVM (NOT RHEV). These BIOS updates [2] provide IBPB support for the Opteron processors running in these systems [3], however I am unable to pass these new features to the virtual guests on the systems as there is no option for Opteron processors in libvirt/qemu/virtual-machine-manager with the IBPB flag (similar to EPYC). Running 'virsh capabilities' shows the latest CPU type that we can use is Opteron_G5, but it also does show ibpb as a CPU feature as well [4]. However, looking at a virtual guest running on the system, it does not show it has the IBPB support [5] and shows it's still vulnerable [6], even after powering off the virtual guest completely and turning it back on.

Unable to protect our virtual guests from the Spectre vulnerability, even when I have official firmware updates from our OEM (Dell), until support for adding the IBPB flag for the Opteron processors is added.


[1]
[root@example ~]# virsh cpu-models --arch x86_64
486
pentium
pentium2
pentium3
pentiumpro
coreduo
n270
core2duo
qemu32
kvm32
cpu64-rhel5
cpu64-rhel6
kvm64
qemu64
Conroe
Penryn
Nehalem
Nehalem-IBRS
Westmere
Westmere-IBRS
SandyBridge
SandyBridge-IBRS
IvyBridge
IvyBridge-IBRS
Haswell-noTSX
Haswell-noTSX-IBRS
Haswell
Haswell-IBRS
Broadwell-noTSX
Broadwell-noTSX-IBRS
Broadwell
Broadwell-IBRS
Skylake-Client
Skylake-Client-IBRS
Skylake-Server
Skylake-Server-IBRS
athlon
phenom
Opteron_G1
Opteron_G2
Opteron_G3
Opteron_G4
Opteron_G5
EPYC
EPYC-IBPB

[2]
http://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverId=TNTXF

[3]
[root@example ~]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    8
Socket(s):             4
NUMA node(s):          8
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD Opteron(tm) Processor 6378
Stepping:              0
CPU MHz:               2400.057
BogoMIPS:              4800.11
Virtualization:        AMD-V
L1d cache:             16K
L1i cache:             64K
L2 cache:              2048K
L3 cache:              6144K
NUMA node0 CPU(s):     0-7
NUMA node1 CPU(s):     8-15
NUMA node2 CPU(s):     32-39
NUMA node3 CPU(s):     40-47
NUMA node4 CPU(s):     48-55
NUMA node5 CPU(s):     56-63
NUMA node6 CPU(s):     16-23
NUMA node7 CPU(s):     24-31
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc art rep_good nopl nonstop_tsc extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate retpoline_amd vmmcall bmi1 ibpb arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold ssbd

[4]
root@example ~]# virsh capabilities
<capabilities>

  <host>
    <uuid>4c4c4544-004b-4a10-8044-b1c04f525731</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Opteron_G5</model>
      <vendor>AMD</vendor>
      <microcode version='100665426'/>
      <topology sockets='1' cores='64' threads='1'/>
      <feature name='vme'/>
      <feature name='ht'/>
      <feature name='monitor'/>
      <feature name='osxsave'/>
      <feature name='bmi1'/>
      <feature name='mmxext'/>
      <feature name='fxsr_opt'/>
      <feature name='cmp_legacy'/>
      <feature name='extapic'/>
      <feature name='cr8legacy'/>
      <feature name='osvw'/>
      <feature name='ibs'/>
      <feature name='skinit'/>
      <feature name='wdt'/>
      <feature name='tce'/>
      <feature name='nodeid_msr'/>
      <feature name='topoext'/>
      <feature name='perfctr_core'/>
      <feature name='perfctr_nb'/>
      <feature name='invtsc'/>
      <feature name='ibpb'/>
      <pages unit='KiB' size='4'/>
      <pages unit='KiB' size='2048'/>
      <pages unit='KiB' size='1048576'/>
    </cpu>
...
...

[5]
[root@[VM running on example above] ~]# lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             2
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD Opteron 63xx class CPU
Stepping:              0
CPU MHz:               2400.028
BogoMIPS:              4800.05
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             64K
L1i cache:             64K
L2 cache:              512K
NUMA node0 CPU(s):     0,1
Flags:                 fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx pdpe1gb lm art rep_good nopl extd_apicid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm abm sse4a misalignsse 3dnowprefetch xop fma4 tbm retpoline_amd vmmcall arat

[6]
[root@[VM running on example above] ~]# cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Vulnerable: Retpoline without IBPB

Where are you experiencing the behavior?  What environment?

Any RHEL 7.5 system running latest updates that use Opteron processors and hosts virtual guests.

[root@ ~]# uname -a
Linux example.com 3.10.0-862.3.2.el7.x86_64 #1 SMP Tue May 15 18:22:15 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

[root@ ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.5 (Maipo)

[root@ ~]# rpm -qa | grep -e libvirt -e qemu
libvirt-libs-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-secret-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-logical-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-kvm-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-nwfilter-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-rbd-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-config-network-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-network-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-qemu-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-mpath-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-iscsi-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-config-nwfilter-3.9.0-14.el7_5.5.x86_64
qemu-kvm-common-1.5.3-156.el7_5.2.x86_64
libvirt-python-3.9.0-1.el7.x86_64
libvirt-daemon-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-core-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-nodedev-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-gluster-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-3.9.0-14.el7_5.5.x86_64
libvirt-client-3.9.0-14.el7_5.5.x86_64
libvirt-3.9.0-14.el7_5.5.x86_64
qemu-img-1.5.3-156.el7_5.2.x86_64
libvirt-daemon-driver-storage-scsi-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-lxc-3.9.0-14.el7_5.5.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
libvirt-daemon-driver-interface-3.9.0-14.el7_5.5.x86_64
libvirt-daemon-driver-storage-disk-3.9.0-14.el7_5.5.x86_64
qemu-kvm-1.5.3-156.el7_5.2.x86_64

Expected results:


Additional info:

Comment 3 Jiri Denemark 2018-05-25 18:44:53 UTC
There's no need for *-IBPB CPU model, just use

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

The special *-IBPB and *-IBRS CPU models were a bad idea anyway since more and
more features required to mitigate various CPU vulnerabilities are coming.

If the tool you're using doesn't allow you to use such configuration, please,
file a bug against that specific tool.


Note You need to log in before you can comment on or make changes to this bug.