Installing a secure boot OVMF of a windows guest with virtio hits the problem tha the viostor.sys or vioscsi.sys driver isn't signed in the secure boot database. https://bugzilla.redhat.com/show_bug.cgi?id=1844726 If I understand it correctly (and I'm far from sure that I do), adding the correct Red Hat certs that they use to sign their virtio-win sys drivers would prevent the secure boot guest failure of Windows (and quite literally hours of trying to understand secure book enough to try to enroll the right cert in the right database). code ref: https://github.com/tianocore/edk2/blob/master/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c#L610 The same Red Hat certificate is the same for all virtio-win drivers: openssl x509 -inform der -in ~dan/Downloads/cert.cer -text --noout Certificate: Data: Version: 3 (0x2) Serial Number: 5d:10:cb:18:eb:3a:79:00:87:83:ab:74:77:f9:d3:19 Signature Algorithm: sha256WithRSAEncryption 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." Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:de:ad:2d:68:8b:5d:95:e7:60:34:5c:eb:2f:6a: 79:0a:e7:37:9f:6a:3f:9c:6e:b6:34:38:00:76:58: fe:6f:44:68:d3:11:cc:a3:8e:36:06:a5:5b:a6:13: 41:1a:d6:e9:e9:88:b1:ca:a5:c1:e4:73:bc:39:eb: 17:88:6f:fe:ef:d2:7c:8a:b5:e9:72:ea:75:58:8b: d2:d6:63:98:55:98:86:28:db:b4:53:f5:72:31:19: 35:e4:b8:ee:6d:98:9d:08:13:a5:3b:0a:99:9e:40: eb:af:e8:8a:ac:e0:f2:88:0d:6f:1c:62:95:43:a8: 8d:0f:ab:8f:38:70:b2:f7:c9:02:09:da:1a:13:8c: 79:1f:35:71:ad:98:b2:0c:c5:5f:76:30:7f:b8:b2: e8:0f:c2:b6:31:c8:3a:1e:fc:c1:cc:11:d0:c6:89: 5b:a4:2f:3a:13:9a:0a:55:61:1c:6b:6a:f3:22:14: 03:b9:3f:de:4f:2c:08:2e:31:23:17:22:d9:4a:85: 39:7a:29:c3:41:14:bd:df:f1:9d:ce:5b:cb:c9:bb: 2d:87:43:3b:4e:3c:b0:e3:34:94:04:ad:d9:de:0f: 2a:78:8e:bd:49:14:fc:ba:6a:88:54:98:a3:fe:b6: ef:68:fe:29:10:43:60:25:b6:22:03:c2:2b:91:d6: 95:93 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: critical Digital Signature X509v3 CRL Distribution Points: Full Name: URI:http://rb.symcb.com/rb.crl X509v3 Certificate Policies: Policy: 2.23.140.1.4.1 CPS: https://d.symcb.com/cps User Notice: Explicit Text: https://d.symcb.com/rpa X509v3 Extended Key Usage: Code Signing Authority Information Access: OCSP - URI:http://rb.symcd.com CA Issuers - URI:http://rb.symcb.com/rb.crt X509v3 Authority Key Identifier: keyid:D4:C0:06:22:49:EB:39:4B:DD:93:E2:5C:A1:B8:47:76:09:72:03:58 X509v3 Subject Key Identifier: 6F:46:65:44:26:18:05:37:7E:51:30:BE:43:41:D0:38:71:DB:7C:69 Signature Algorithm: sha256WithRSAEncryption 57:df:a0:11:52:88:43:3a:17:55:e7:64:f7:8a:66:fe:61:15: 5d:96:6e:24:f5:e5:f8:9a:d1:3f:67:ed:ef:4e:e4:06:78:22: a0:44:5a:35:d3:0f:78:81:0a:d1:09:10:90:75:f7:b2:46:c2: 47:4a:f6:05:6e:07:46:7f:e3:5b:a0:ec:57:d8:c0:d0:17:d0: 11:1b:0e:83:98:87:b3:56:f3:49:0a:79:e0:bf:5f:54:2e:8d: 55:ac:30:c7:f6:dc:92:69:f9:9b:d4:f1:63:91:8c:1c:97:c6: bf:8b:63:16:42:a3:3f:7a:b9:de:cb:d6:87:14:71:a2:5a:21: 9f:5a:ef:06:59:cd:5f:9a:76:5d:1b:42:e3:97:32:d6:9f:ec: ef:60:a9:91:13:7d:2f:fc:76:fc:ad:18:57:a4:40:14:52:f6: 81:e2:d3:68:f1:a8:50:0a:5d:34:9c:40:6c:af:bb:4d:28:b6: 9b:7f:d3:9f:c5:72:e9:de:88:8c:45:fc:d6:2c:11:b8:4d:ab: c7:e6:05:92:e4:c8:17:06:23:fa:5b:18:9d:7f:dd:ef:32:43: 37:91:a6:11:46:3f:b7:de:51:dd:72:16:a9:c8:ab:56:ce:0b: e1:1d:af:24:8c:30:41:e6:83:97:62:17:34:f3:3a:9b:7c:ca: 5f:f6:f3:66 I wish I could say I have a work around however at least the 20200201stable fc32 packaged versions of edk2-ovmffor OVMF_CODE.secboot.fd fails to save the Secure Boot Mode = Custom Mode and also in DB Options -> Enroll Signature Using file x509 DER formatted Redhat.der (is a signature GUID required? where's this from?) fais to save (Looking at the delete signature list theres theres a 00000...0000 GUID entry)
Hi Daniel, given that this is vendor-specific, I suggest that we continue discussing it in RHBZ#1844726 (as you linked it in comment#0). I'm going to close the upstream tracker as INVALID for now, as EnrollDefaultKeys.efi would likely spiral out-of-hand if we attempted to include certificates from numerous vendors in it. What EnrollDefaultKeys is supposed to do at the moment is to mirror physical platforms. On a physical platform, you generally find the Microsoft certificates enrolled: - "Microsoft Corporation KEK CA 2011" in KEK, - "Microsoft Windows Production PCA 2011" in db, - "Microsoft Corporation UEFI CA 2011" in db, - the platform vendor's certificate in PK and KEK, - some forbidden hashes in dbx. EnrollDefaultKeys.efi lets you specify the platform vendor's certificate (for PK and KEK) in the "OEM Strings" (type 11) SMBIOS table. The RHEL package already uses a RH-specific certificate for that -- on the other hand, that one probably doesn't make Windows accept the *unsigned* virtio-win drivers. (And I'm not sure about the Fedora status.) Either way, this is an OS-driver signing question. Let's continue in the RHBZ, and I'll ask some colleagues that work on virtio-win to look at it. Thanks.
(Update to comment 1: for comments on the "dbx" put in place by EnrollDefaultKeys.efi, see the "mSha256OfDevNull" variable in "OvmfPkg/EnrollDefaultKeys/AuthData.c". There is no intent to distribute and/or keep refreshing <http://www.uefi.org/revocationlistfile> within OvmfPkg.)
