Bug 1844726
Summary: | viostor causes Windows 10 boot failure if Secure Boot is enabled | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Kevin Locke <kevin> |
Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | menli <menli> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | 47b13, ailan, christoph.obexer, crobinso, dholler, haoliu, jinzhao, juzhang, lersek, lijin, mdean, mkedzier, myeservices+fedoraproject.org, remasch, transvita, tyler, virt-maint, vrozenfe, ybendito, yvugenfi |
Target Milestone: | --- | Keywords: | MigratedToJIRA |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Windows | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-10-03 11:30:26 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kevin Locke
2020-06-06 16:24:49 UTC
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. |