Description of problem: Windows 10 2004 fails to boot after installation with the viostor driver in a VM using OVMF UEFI configured with Secure Boot enabled. Version-Release number of selected component (if applicable): Issue occurs with either virtio-win-0.1.171.iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso or virtio-win-0.1.185.iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso How reproducible: Always Steps to Reproduce: 1. Download Windows 10 2004 English from https://www.microsoft.com/en-us/software-download/windows10ISO 2. Create a VM with os loader OVMF_CODE.ms.fd, virtio disk, Win10_2004_English_x64.iso disk, and virtio-win.iso disk. 3. Win10_2004_English_x64.iso, install Windows loading the disk driver from viostor/w10/amd64 during partitioning. Actual results: After the Windows installation completes and the VM reboots, it displays a blue screen with the following content: Recovery Your PC/Device needs to be repaired The operating system couldn't be loaded because the digital signature of a file or one of its dependencies couldn't be verified. File: \Windows\System32\drivers\viostor.sys Error code: 0xc0000428 You'll need to use recovery tools. If you don't have any installation media (like a disc or USB device), contact your PC administrator or PC/Device manufacturer. Expected results: The installation would either work, or the lack of Secure Boot support would be documented. Additional info: Based on the Windows Driver Signing Policy <https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-#signing-requirements-by-version> this may be expected behavior. <https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/README.md> says the drivers that ship with RHEL are signed (but not WHQL signed due to the GPL - but the LICENSE is BSD-3!?). <https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html#fedora-virtio-drivers-vs-rhel> says they are not WHQL signed. Is attestation signing also restricted to non-GPL binaries? It would be helpful if the documentation could be clearer about which binaries are signed in what ways. If it is expected that the drivers will prevent Windows from booting when Secure Boot is enabled, it would be helpful to add a warning to https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html and other relevant docs so users are aware of this limitation and the source of the above error, should they encounter it. (I can submit a PR to quick-docs once I understand.) Thanks, Kevin
Red Hat donates non-WHQL signed virtio-win drivers to community by making them available to community on fedoraproject.org Due to our policy WHQL-signed drivers available to RH customers only. Attestation signature should solve UEFI/Secure Boot problem. AFAIK, Yan is working on it.
Good to know. That explains a lot. Thanks for taking the time to explain it!
Most probably, Red Hat will not add attestation-signed drivers on the virtio-win project upstream Anyone interested can do it AFAIU
It looks like all the sys files (at least the w10 versions of 0.1.171) I tested with with (windows) `SignTool verify /v /pa *.sys` where the drivers are signed with the Red Hat code signing certificate. Is that different from an Attestation certificate? I've had trouble enrolling that x509 der cerificate into the DB usingthe Custom Mode of secure boot with OVMF (bug #1871403 + upstream). Maybe I need to specify a Signature GUID however I don't know what that is. Has anyone succeeded in this? Is the secure boot DB store where it needs to be enrolled or is it elsewhere?
(In reply to Daniel Black from comment #4) > It looks like all the sys files (at least the w10 versions of 0.1.171) I > tested with with (windows) `SignTool verify /v /pa *.sys` where the drivers > are signed with the Red Hat code signing certificate. Is that different from > an Attestation certificate? > > I've had trouble enrolling that x509 der cerificate into the DB usingthe > Custom Mode of secure boot with OVMF (bug #1871403 + upstream). Maybe I need > to specify a Signature GUID however I don't know what that is. Has anyone > succeeded in this? > > Is the secure boot DB store where it needs to be enrolled or is it elsewhere? Hi Daniel, If you own RHEL subscription, then you also should be able to get access to virtio-win package which contains WHQL signed drivers. Vadim.
CC'ing Cole and a few other people. I've closed upstream TianoCore bug <https://bugzilla.tianocore.org/show_bug.cgi?id=2921> as INVALID now, as we shouldn't include various vendor certificates in upstream edk2 / OvmfPkg. Microsoft is clearly an exception, as their certificates are universally pre-installed on physical x86 platforms. The edk2-ovmf package on Fedora comes with a variable store template file that has the Secure Boot operational mode enabled. The certificate set enrolled in this varstore template matches my generic description at <https://bugzilla.tianocore.org/show_bug.cgi?id=2921#c1> and <https://bugzilla.tianocore.org/show_bug.cgi?id=2921#c2>, with the vendor-specific bit that for PK and first KEK, we enroll the self-signed certificate called "RedHatSecureBootPkKek1.pem" in the Source RPM: Issuer: CN=Red Hat Secure Boot (PK/KEK key 1)/emailAddress=secalert Validity Not Before: Oct 31 11:15:37 2014 GMT Not After : Oct 25 11:15:37 2037 GMT Subject: CN=Red Hat Secure Boot (PK/KEK key 1)/emailAddress=secalert I don't know whether this certificate is sufficient for Windows to silently accept the Fedora-distributed virtio-win drivers: (1) I don't know whether Windows considers PK and/or KEK (and/or "db") contents when verifying native OS driver signatures, and (2) it's likely that the virtio-win drivers in Fedora do *not* carry a certificate chain that is rooted in the above-quoted "Red Hat Secure Boot (PK/KEK key 1)" certificate. In <https://bugzilla.tianocore.org/show_bug.cgi?id=2921#c0>, Daniel implies that virtio-win (in Fedora) is signed with the following: Issuer: C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 SHA256 Code Signing CA - G2 Validity Not Before: Nov 27 00:00:00 2018 GMT Not After : Jan 25 23:59:59 2022 GMT Subject: C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", CN = "Red Hat, Inc." I still don't know whether adding this certificate to e.g. "db" would make Windows accept the Fedora-distributed virtio-win drivers silently. (And even if it worked, I'm unconvinced we'd *pre-enroll* this certificate in "db" in the Fedora package -- that decision is not up to me, to say the least.) For a manual try, - First copy the certificate in question to the ESP (EFI system partition) of the guest in question, while the guest is shut down. (Alternatively, format a separate virtual disk or ISO image with the certificate, and attach that device to the guest config.) - Boot the guest, drop to the Setup TUI, and navigate to Device Manager | Secure Boot Configuration. - Set Secure Boot Mode to "Custom Mode"; enter "Custom Secure Boot Options". - Enter "DB Options" -- this is where question (1) becomes relevant; if Windows considers the firmware auth variables *at all* (which I don't know), then it most likely considers "db". - Enter "Enroll Signature", then "Enroll Signature Using File". Locate the certificate file on the ESP / FAT partition discussed above. - For signature GUID, enter *any* guid that you generate with "uuidgen". (The signature owner GUID field has two interpretations. Per UEFI spec, it is the GUID of the *agent* that enrolled the certificate, so one is free to generate any valid GUID with "uuidgen" for example. However, Microsoft considers "signature owner" to mean the organization that published the certificate; so in their SVVP checks, they insist on various certificates being associated with their particular GUID. This conflicting interpretation notwithstanding, for manual enrollment, it's usually best to generate a new GUID with "uuidgen".) - Hit "Commit Changes and Exit", then navigate to the outermost menu, and select "Reset".
(In reply to Laszlo Ersek from comment #6) > CC'ing Cole and a few other people. > > I've closed upstream TianoCore bug > <https://bugzilla.tianocore.org/show_bug.cgi?id=2921> as INVALID now, as we > shouldn't include various vendor certificates in upstream edk2 / OvmfPkg. > Microsoft is clearly an exception, as their certificates are universally > pre-installed on physical x86 platforms. > > The edk2-ovmf package on Fedora comes with a variable store template file > that has the Secure Boot operational mode enabled. The certificate set > enrolled in this varstore template matches my generic description at > <https://bugzilla.tianocore.org/show_bug.cgi?id=2921#c1> and > <https://bugzilla.tianocore.org/show_bug.cgi?id=2921#c2>, with the > vendor-specific bit that for PK and first KEK, we enroll the self-signed > certificate called "RedHatSecureBootPkKek1.pem" in the Source RPM: > > Issuer: CN=Red Hat Secure Boot (PK/KEK key > 1)/emailAddress=secalert > Validity > Not Before: Oct 31 11:15:37 2014 GMT > Not After : Oct 25 11:15:37 2037 GMT > Subject: CN=Red Hat Secure Boot (PK/KEK key > 1)/emailAddress=secalert > > I don't know whether this certificate is sufficient for Windows to silently > accept the Fedora-distributed virtio-win drivers: > > (1) I don't know whether Windows considers PK and/or KEK (and/or "db") > contents when verifying native OS driver signatures, and > > (2) it's likely that the virtio-win drivers in Fedora do *not* carry a > certificate chain that is rooted in the above-quoted "Red Hat Secure Boot > (PK/KEK key 1)" certificate. > > In <https://bugzilla.tianocore.org/show_bug.cgi?id=2921#c0>, Daniel implies > that virtio-win (in Fedora) is signed with the following: > > Issuer: C = US, O = Symantec Corporation, OU = Symantec Trust > Network, CN = Symantec Class 3 SHA256 Code Signing CA - G2 > Validity > Not Before: Nov 27 00:00:00 2018 GMT > Not After : Jan 25 23:59:59 2022 GMT > Subject: C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, > Inc.", CN = "Red Hat, Inc." > > I still don't know whether adding this certificate to e.g. "db" would make > Windows accept the Fedora-distributed virtio-win drivers silently. (And even > if it worked, I'm unconvinced we'd *pre-enroll* this certificate in "db" in > the Fedora package -- that decision is not up to me, to say the least.) > > For a manual try, > > - First copy the certificate in question to the ESP (EFI system partition) > of the guest in question, while the guest is shut down. (Alternatively, > format a separate virtual disk or ISO image with the certificate, and attach > that device to the guest config.) > > - Boot the guest, drop to the Setup TUI, and navigate to Device Manager | > Secure Boot Configuration. > > - Set Secure Boot Mode to "Custom Mode"; enter "Custom Secure Boot Options". > > - Enter "DB Options" -- this is where question (1) becomes relevant; if > Windows considers the firmware auth variables *at all* (which I don't know), > then it most likely considers "db". > > - Enter "Enroll Signature", then "Enroll Signature Using File". Locate the > certificate file on the ESP / FAT partition discussed above. > > - For signature GUID, enter *any* guid that you generate with "uuidgen". > > (The signature owner GUID field has two interpretations. Per UEFI spec, it > is the GUID of the *agent* that enrolled the certificate, so one is free to > generate any valid GUID with "uuidgen" for example. However, Microsoft > considers "signature owner" to mean the organization that published the > certificate; so in their SVVP checks, they insist on various certificates > being associated with their particular GUID. This conflicting interpretation > notwithstanding, for manual enrollment, it's usually best to generate a new > GUID with "uuidgen".) > > - Hit "Commit Changes and Exit", then navigate to the outermost menu, and > select "Reset". @yvugenfi can you please assist? Thanks, Meirav.
Since Microsoft has removed the capability of permanently disable Driver Signature Enforcement without the need to disable secureboot. Any updates to the Attestation signature which should solve UEFI/Secure Boot problem?
We are in the process of updating virtio-win packaging / RPM build. Attestation signed drivers for Win10 platform supposed to be included into RPM as part of this activity. Vadim.
(In reply to Vadim Rozenfeld from comment #11) > We are in the process of updating virtio-win packaging / RPM build. > Attestation signed drivers for Win10 platform supposed to be included > into RPM as part of this activity. > > Vadim. Hi, I've been following this thread since I would like to use Secure Boot on Win10 VM with virtio drivers, and unfortunately it seems that I need WHQL version for successful installation of the IVSHMEM device driver. Is there any update since 6/28/21 on the updating of virtio-win packaging/RPM build for attestation signed rivers for Win10? I would love to get a hold of it some how. Thanks!
(In reply to transvita from comment #12) > (In reply to Vadim Rozenfeld from comment #11) > > We are in the process of updating virtio-win packaging / RPM build. > > Attestation signed drivers for Win10 platform supposed to be included > > into RPM as part of this activity. > > > > Vadim. > > Hi, I've been following this thread since I would like to use Secure Boot on > Win10 VM with virtio drivers, and unfortunately it seems that I need WHQL > version for successful installation of the IVSHMEM device driver. Is there > any update since 6/28/21 on the updating of virtio-win packaging/RPM build > for attestation signed rivers for Win10? > > I would love to get a hold of it some how. > > Thanks! We do have attestation signed drivers at https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.204-1/ Unfortunately, IVSHMEM is not a part of our "official" build. We can re-consider this decision and add IVSHMEM to the build, but it will take some time to make it work. Best regards, Vadim.
(In reply to Vadim Rozenfeld from comment #13) > (In reply to transvita from comment #12) > > (In reply to Vadim Rozenfeld from comment #11) > > > We are in the process of updating virtio-win packaging / RPM build. > > > Attestation signed drivers for Win10 platform supposed to be included > > > into RPM as part of this activity. > > > > > > Vadim. > > > > Hi, I've been following this thread since I would like to use Secure Boot on > > Win10 VM with virtio drivers, and unfortunately it seems that I need WHQL > > version for successful installation of the IVSHMEM device driver. Is there > > any update since 6/28/21 on the updating of virtio-win packaging/RPM build > > for attestation signed rivers for Win10? > > > > I would love to get a hold of it some how. > > > > Thanks! > > We do have attestation signed drivers at > https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive- > virtio/virtio-win-0.1.204-1/ > Unfortunately, IVSHMEM is not a part of our "official" build. We can > re-consider this decision and add IVSHMEM to the build, but it will take > some time to make it work. > > Best regards, > Vadim. Thanks for your reply. I don't know how much work is involved in adding IVSHMEM to an official build, or if I can grab an unofficial build that has IVSHMEM added, but would appreciate it if it could be added to a build in the near future. I think I may not be the only one that would find this useful.
Just downloaded and used the drivers. they work and can boot with Secure Boot enabled. However, PVPanic is still not signature attested. Can't use the device at all without that attestation. However, Windows will boot.
qxldod driver doesn´t seem to work under Windows 10 with Secure Boot enabled.
Ignore/delete my comment above and this one. Thanks for all the work. Best regards
All the drivers we distribute downstream are signed with attestation signing.