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 1961761 - Enabling Device Guard in Windows on RHV 4.4 gives BSOD on reboot
Summary: Enabling Device Guard in Windows on RHV 4.4 gives BSOD on reboot
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: unspecified
Hardware: x86_64
OS: Windows
high
high
Target Milestone: rc
: ---
Assignee: Marek Kedzierski
QA Contact: menli@redhat.com
Jiri Herrmann
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-18 16:18 UTC by Robert McSwain
Modified: 2024-10-01 18:14 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-25 02:46:32 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Robert McSwain 2021-05-18 16:18:59 UTC
Description of problem:
Enabling Device Guard in Windows on RHV 4.4 gives a Windows StopCode BSOD on reboot

"Stop code: DRIVER VERIFIER DETECTED VIOLATION

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

RHV 4.4

How reproducible:
100% for this customer

Steps to Reproduce:
See steps in comment #12 here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1496170#c12

Actual results:
BSOD stop code returned by Windows

Expected results:
This should be allowed by the OS and passed through properly, as this seemed to work as of RHBA-2017:31007-01 - https://errata.devel.redhat.com/advisory/31007

Comment 3 Xueqiang Wei 2021-05-20 16:44:04 UTC
It may be cpu flags related issue.

The similar bug:
Bug 1871670 - windows guest can not boot after reboot with Device Guard enabled  - CLOSED WONTFIX


Could you please help recheck the following two items? Many thanks.

1. Booting the guest with all currently supported Hyper-V enlightenmetns. And then check whether hit this bug.

2. Disabling Hyper-V enlightenmetns, check whether hit this bug.


cpu flags like:
-cpu 'Opteron_G5',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \

Or
-cpu 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt  \



According to https://bugzilla.redhat.com/show_bug.cgi?id=1871670#c25, I tested it with all currently supported Hyper-V enlightenmetns, not hit this issue. 


I tried it on rhel8.3 and rhel8.4.

Versions:
Host RHEL8.3:
kernel-4.18.0-240.el8.x86_64
qemu-kvm-4.2.0-34.module+el8.3.0+10437+1ca0c2ba.5
edk2-ovmf-20200602gitca407c7246bf-3.el8.noarch

Guest:
win2016 with virtio-win-1.9.16-2


Host RHEL8.4:
kernel-4.18.0-305.el8.x86_64
qemu-kvm-5.2.0-16.module+el8.4.0+10806+b7d97207
edk2-ovmf-20200602gitca407c7246bf-4.el8_4.1.noarch

Guest:
win2016 with virtio-win-1.9.16-2



Test steps:
1.start a win2016 guest

/usr/libexec/qemu-kvm \
    -S  \
    -name 'avocado-vt-vm1'  \
    -sandbox on  \
    -blockdev node-name=file_ovmf_code,driver=file,filename=/usr/share/OVMF/OVMF_CODE.secboot.fd,auto-read-only=on,discard=unmap \
    -blockdev node-name=drive_ovmf_code,driver=raw,read-only=on,file=file_ovmf_code \
    -blockdev node-name=file_ovmf_vars,driver=file,filename=/home/kvm_autotest_root/images/avocado-vt-vm1_win2016-64-virtio-scsi.qcow2_VARS.fd,auto-read-only=on,discard=unmap \
    -blockdev node-name=drive_ovmf_vars,driver=raw,read-only=off,file=file_ovmf_vars \
    -machine q35,pflash0=drive_ovmf_code,pflash1=drive_ovmf_vars \
    -device pcie-root-port,id=pcie-root-port-0,multifunction=on,bus=pcie.0,addr=0x1,chassis=1 \
    -device pcie-pci-bridge,id=pcie-pci-bridge-0,addr=0x0,bus=pcie-root-port-0  \
    -nodefaults \
    -device VGA,bus=pcie.0,addr=0x2 \
    -m 30720  \
    -smp 12,maxcpus=12,cores=6,threads=1,dies=1,sockets=2  \
    -cpu 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt  \
    -chardev socket,id=qmp_id_qmpmonitor1,wait=off,server=on,path=/tmp/avocado_or3cdzmf/monitor-qmpmonitor1-20210520-112138-lIGOyFgO  \
    -mon chardev=qmp_id_qmpmonitor1,mode=control \
    -chardev socket,id=qmp_id_catch_monitor,wait=off,server=on,path=/tmp/avocado_or3cdzmf/monitor-catch_monitor-20210520-112138-lIGOyFgO  \
    -mon chardev=qmp_id_catch_monitor,mode=control \
    -device pvpanic,ioport=0x505,id=id0XVSLL \
    -chardev socket,id=chardev_serial0,wait=off,server=on,path=/tmp/avocado_or3cdzmf/serial-serial0-20210520-112138-lIGOyFgO \
    -device isa-serial,id=serial0,chardev=chardev_serial0  \
    -chardev socket,id=seabioslog_id_20210520-112138-lIGOyFgO,path=/tmp/avocado_or3cdzmf/seabios-20210520-112138-lIGOyFgO,server=on,wait=off \
    -device isa-debugcon,chardev=seabioslog_id_20210520-112138-lIGOyFgO,iobase=0x402 \
    -device pcie-root-port,id=pcie-root-port-1,port=0x1,addr=0x1.0x1,bus=pcie.0,chassis=2 \
    -device qemu-xhci,id=usb1,bus=pcie-root-port-1,addr=0x0 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
    -device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie-root-port-2,addr=0x0 \
    -blockdev node-name=file_image1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kvm_autotest_root/images/win2016-64-virtio-scsi.qcow2,cache.direct=on,cache.no-flush=off \
    -blockdev node-name=drive_image1,driver=qcow2,read-only=off,cache.direct=on,cache.no-flush=off,file=file_image1 \
    -device scsi-hd,id=image1,drive=drive_image1,write-cache=on \
    -device pcie-root-port,id=pcie-root-port-3,port=0x3,addr=0x1.0x3,bus=pcie.0,chassis=4 \
    -device virtio-net-pci,mac=9a:bb:02:2a:aa:77,id=idM0i9R2,netdev=idwDIh6t,bus=pcie-root-port-3,addr=0x0  \
    -netdev tap,id=idwDIh6t,vhost=on \
    -blockdev node-name=file_cd1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kvm_autotest_root/iso/windows/winutils.iso,cache.direct=on,cache.no-flush=off \
    -blockdev node-name=drive_cd1,driver=raw,read-only=on,cache.direct=on,cache.no-flush=off,file=file_cd1 \
    -device scsi-cd,id=cd1,drive=drive_cd1,write-cache=on  \
    -vnc :0  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot menu=off,order=cdn,once=c,strict=off \
    -enable-kvm \
    -monitor stdio \

2.enable secure boot
3.download Device Guard and enable it
4.reboot the guest

Comment 19 Marek Kedzierski 2021-06-12 17:56:21 UTC
By mistake I removed needinfo from Robert and Michal - sorry!

Comment 23 menli@redhat.com 2021-06-17 09:27:01 UTC
I tried it on win2016 on rhel8.3 with following steps,not hit this issue. 

Versions:
Host RHEL8.3:
kernel-4.18.0-240.el8.x86_64
qemu-kvm-4.2.0-34.module+el8.3.0+10437+1ca0c2ba.5
edk2-ovmf-20200602gitca407c7246bf-3.el8.noarch
virtio-win-1.9.14-4


Test steps:
1.start a win2016 guest(with secure boot enable)

 /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm3' \
    -machine q35 \
    -nodefaults \
    -vga std  \
    -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 \
    -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
    -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
    -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
    -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
    -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
    -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
    -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
    -device virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.4 \
    -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/kvm_autotest_root/images/win2016-64-virtio-scsi.qcow2,node-name=data_node \
    -blockdev driver=qcow2,node-name=data_disk,file=data_node \
    -device scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \
    -device virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3  \
    -netdev tap,id=id23ZUK6,vhost=on \
    -m 4G  \
    -smp 2,maxcpus=4 \
    -cpu 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt  \
    -drive id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/ISO/Win2016/en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.iso \
    -device ide-cd,id=cd2,drive=drive_cd1,bus=ide.0,unit=0 \
    -cdrom /home/kvm_autotest_root/iso/windows/virtio-win-1.9.14-4.el8.iso \
    -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \
    -vnc :10  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -qmp tcp:0:1231,server,nowait \
    -monitor stdio \
    -device virtio-serial-pci,id=virtio-serial1,max_ports=31,bus=pci.5  \
    -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait  -device virtserialport,bus=virtio-serial1.0,chardev=channel2,name=org.qemu.guest_agent.0,id=port2 \
    -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,bus=pci.6 \
    -device virtio-balloon-pci,id=balloon0,bus=pci.7 \
    -device pvpanic,id=pvpanic0,ioport=0x0505  \
    -device virtio-keyboard-pci,id=kbd0,serial=virtio-keyboard,bus=pci.8 -device virtio-mouse-pci,id=mouse0,serial=virtio-mouse  -device virtio-tablet-pci,id=tablet0,serial=virtio-tablet  \
    -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
    -numa node,memdev=mem \
    -chardev socket,id=char0,path=/tmp/vhostqemu \
    -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \
    -blockdev node-name=file_stg2,driver=file,cache.direct=on,cache.no-flush=off,filename=/home/test/data1.qcow2,aio=threads \
    -blockdev node-name=drive_stg2,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_stg2 \
    -device virtio-blk-pci,id=stg2,drive=drive_stg2 \
    -drive file=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on  \
    -drive file=/home/OVMF_VARS.secboot.fd,if=pflash,format=raw,unit=1 \

2.download Device Guard and enable it
3.reboot the guest

boot the guest (remove all hyperv flags ), repeat steps 2 and 3, also not hit the issue.


Thanks
Menghuan

Comment 27 Eric Hadley 2021-09-08 16:57:39 UTC
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Comment 29 xiagao 2021-10-26 01:32:07 UTC
@zhguo,
Could you help check this issue, do you have any ideas?

Xiaoling

Comment 46 Qianqian Zhu 2022-01-25 02:46:32 UTC
I am closing it since the customer issue has already been closed as configure issue, and QE has verified that without vmx there is no such issue.
Please feel free to reopen it if you still hit the issue.

Comment 50 Qianqian Zhu 2022-05-05 07:27:57 UTC
Hi Marek,

I am not sure if this should be documented as a known issue, or should we move the solution to INVALID if we don't need the document?

Comment 51 Marek Kedzierski 2022-05-05 11:36:39 UTC
(In reply to Qianqian Zhu from comment #50)
> Hi Marek,
> 
> I am not sure if this should be documented as a known issue, or should we
> move the solution to INVALID if we don't need the document?

Hi Qianqian, 

I think this configuration is invalid, so it should not be documented.

Thanks, 

Marek

Comment 52 Qianqian Zhu 2022-05-06 02:05:39 UTC
Thanks Marek, I am moving it to NOTABUG and remove doc type per comment 51.


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