Description of problem: shim is currently signed with a UEFI (MS) signature and a Fedora signature. In the past, before this was part of the specification it was assumed that a packed list of signatures would be okay. Unfortunately, when the spec added support for this, they chose to require aligned entries. pesign must be updated to support this.
pjones suggested this as a blocker. He writes: <pjones> well, 963361 causes boot failures :/ <pjones> on newer hardware (and notably newer OVMF builds) I'm definitely +1 FE, probably +1 blocker since this is affecting existing SB implementations.
This only affects the latest and greatest hardware out there right +1 FE -1. Workaround users can always disable secure boot
-1 Beta blocker that is
I'm definitely +1 FE, for blocker - depends on how many machines could be affected by this one (newer hardware does not say that - could you clarify it?). Peter, how much work would it be to add the propores support for aligned entries?
There are enough +1 FE votes to mark this acceptedFE, so I'll do that at least. Blocker status is still undecided.
Created attachment 750428 [details] shim binaries re-signed with (a) pesign-0.104-1.fc19, (b) sbsign/951ee95a "pesign-0.104-1.fc19" <https://koji.fedoraproject.org/koji/buildinfo?buildID=419603> claims to fix this BZ so I gave it a shot with OVMF to see whether it satisfies edk2 svn r14141. (I used a current edk2 svn checkout.) The guest I'm using with OVMF is Fedora 19 Alpha TC5. (1) First of all if someone wants to test Secure Boot with bleeding edge OVMF, the following patch *and* its dependencies (listed in the posting) are strongly recommended: [PATCH] OvmfPkg: sustain boot options in the SECURE_BOOT_ENABLE build <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2856> (2) As usual I extracted the RH test certificate and test CA certificate from the pesign package as I wrote in <http://www.linux-kvm.org/page/OVMF#Confirmation_of_secure_boot_in_Fedora_18>, with something like certutil -L -d f18-keys/ -n 'Red Hat Test CA' -r \ >'RedHatTestCA'.der certutil -L -d f18-keys/ -n 'Red Hat Test Certificate' -r \ >RedHatTestCertificate.der (The certificates are identical between .fc18 and .fc19 builds of pesign.) (3) I enrolled these in OVMF as PK and KEK, respectively, plus the latter one also in DB. I tried to boot both "EFI/fedora/shim-fedora.efi" (only signed with the RH test key) and "EFI/fedora/shim.efi" (dual signed with the RH test key and the Microsoft key AFAICS). These files belong to the "shim-0.2-3.2.fc18" package and are installed by Anaconda. OVMF with Secure Boot enabled and the above keys enrolled rejected each of them. I assumed these files had been signed with an older version of pesign (ie. one that doesn't contain the fix for this BZ). IOW with step (3) I only reproduced the bug. Then I installed "pesign-0.104-1.fc19" from Koji in the guest. (4) I figured I would re-sign shim with "pesign-0.104-1" and retry. As cheat sheet I referred to <http://jwboyer.livejournal.com/46149.html>. I took the unsigned shim binary from the "shim-unsigned-0.2-3.fc18" as basis, and ran the following: pesign -c 'Red Hat Test Certificate' -i /usr/share/shim/shim.efi \ -o /boot/efi/EFI/fedora/shim-rhtest-pesign104.efi -s Then I re-ran step (3) -- enrolled the same RH test keys etc --, and the image verification *rejected* "shim-rhtest-pesign104.efi". I guess this means the bug wasn't (completely) fixed, but of course my attempt to re-sign the unsigned shim binary may have been bogus. (5) In any case I also tried with sbsigntools (cheatsheet: <http://blog.hansenpartnership.com/uefi-secure-boot/>). I built it from source at commit 951ee95a. Of course some additional massage was necessary for the cert files, because sbsign only consumes PEM encoding: # convert self-signed public part of KEK, from step (2), to PEM format openssl x509 -inform DER -outform PEM -in RedHatTestCertificate.der \ -out RedHatTestCertificate.pem # extract private part of KEK in PEM format pk12util -o RedHatTestKey.p12 -n 'Red Hat Test Certificate' \ -d f18-keys openssl pkcs12 -in RedHatTestKey.p12 -out RedHatTestKey.pem -nocerts \ -nodes (6) Again I took the unsigned shim binary from the "shim-unsigned-0.2-3.fc18" as basis, and ran the following: ../sbsign --verbose --key RedHatTestKey.pem \ --cert RedHatTestCertificate.pem \ --output /boot/efi/EFI/fedora/shim-rhtest-sbsign.efi \ /usr/share/shim/shim.efi This complained with warning: data remaining[1234944 vs 1360287]: gaps between PE/COFF sections? but produced the output file nevertheless. I re-ran step (3) -- enrolling the same RH test keys etc --, and "shim-rhtest-sbsign.efi" was *rejected* by image verification too. I'm attaching the following files for analysis, perhaps: -rw-r--r-- root/root 1360287 2012-12-12 16:15 usr/share/shim/shim.efi -rwx------ root/root 1363120 2013-05-20 00:45 boot/efi/EFI/fedora/shim-rhtest-pesign104.efi -rwx------ root/root 1362207 2013-05-20 01:08 boot/efi/EFI/fedora/shim-rhtest-sbsign.efi I don't know if the above results are due to PEBKAC over here, or remaining misunderstandings between TianoCore and both of pesign and sbsign. FWIW, if I convert the test *CA* cert to PEM format too (see the x509 command in step (5)), then sbverify accepts both images: ../sbverify --verbose --cert RedHatTestCA.pem \ /boot/efi/EFI/fedora/shim-rhtest-pesign104.efi warning: data remaining[1237776 vs 1363120]: gaps between PE/COFF sections? image signature issuers: - /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA image signature certificates: - subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certificate issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA - subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA certificate store: - subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA Signature verification OK ../sbverify --verbose --cert RedHatTestCA.pem \ /boot/efi/EFI/fedora/shim-rhtest-sbsign.efi warning: data remaining[1236864 vs 1362207]: gaps between PE/COFF sections? image signature issuers: - /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA image signature certificates: - subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certificate issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA certificate store: - subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./CN=Red Hat Test Certifying CA Signature verification OK
Created attachment 750467 [details] shim-0.2-3 rebuilt with gnu-efi-3.0s-2.fc19, and signed with pesign-0.104-1.fc19 / sbsign-951ee95a (bugzilla maintenance kicked in before I could have posted this, soon after comment 6) Looks like "gaps between PE/COFF sections" could be the culprit: search the following articles for that very string: <http://mjg59.dreamwidth.org/6503.html> > Oct. 19th, 2011 10:05 am > > [...] > > Each section of a PE-COFF file is added together and a hash taken[1]. > > [...] > > [1] Hilariously, Microsoft's signing tool gets this wrong by also adding > the contents of gaps between sections in direct contravention of their own > specification. This is fine for binaries generated by Microsoft's > toolchain because they don't have any gaps, but since our binaries do > contain gaps[2] and since the standard firmware implementation[3] does > implement the specification correctly, any Linux-generated binaries signed > with the Microsoft tool fail validation. Go team. > > [2] Something that is, as far as we can tell, permitted by the PE-COFF > specification > > [3] Written by Intel, not Microsoft <http://www.rodsbooks.com/efi-bootloaders/secureboot.html> > Originally written: 11/4/2012; last update: 2/3/2013 > > [...] > > Another warning I've seen on binaries produced with GNU-EFI also seems > harmless: > > warning: data remaining[1231832 vs 1357089]: gaps between PE/COFF > sections? > > On the other hand, the ChangeLog file for GNU-EFI indicates that binaries > created with GNU-EFI versions earlier than 3.0q may not boot in a Secure > Boot environment when signed, [...] This suggests that my unsigned input image, "/usr/share/shim/shim.efi", wasn't proper. I guess the "shim-0.2-3" RPM should be rebuilt with "gnu-efi-3.0s-2.fc19" (since "q" < "s") and retested. ... Unfortunately, a shim binary rebuilt like this, and signed with pesign, or signed with sbsign, or not signed at all, (a) is again refused by image verification (BTW sbsign continues to complain about "gaps between PE/COFF sections" even with this new unsigned shim binary), (b) if Secure Boot is disabled, they load but reset the VM instead of loading grub2. Attaching these too: -rwx------ root/root 1348166 2013-05-20 02:28 boot/efi/EFI/fedora/shim-unsigned.efi -rwx------ root/root 1351000 2013-05-20 02:15 boot/efi/EFI/fedora/shim-rhtest-pesign104.efi -rwx------ root/root 1350086 2013-05-20 02:19 boot/efi/EFI/fedora/shim-rhtest-sbsign.efi
Discussed at 2013-05-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-20/f19beta-blocker-review-7.2013-05-20-16.07.log.txt . Rejected as a blocker as the limited data we have indicate this doesn't really affect enough cases to block the Beta for. Note it is already accepted as a freeze exception bug, so a fix for this can go in RC3 as long as it's ready in time.
I am hereby confirming that "pesign-0.104-1.fc19" <https://koji.fedoraproject.org/koji/buildinfo?buildID=419603> fixes this bug, and that it enables F19 Alpha TC5 secure boot on current OVMF master. I reused "shim-rhtest-pesign104.efi" (size 1363120, attachment 750428 [details], in comment 6), prepared as: > (4) I figured I would re-sign shim with "pesign-0.104-1" and retry. As > cheat sheet I referred to <http://jwboyer.livejournal.com/46149.html>. > > I took the unsigned shim binary from the "shim-unsigned-0.2-3.fc18" as > basis, and ran the following: > > pesign -c 'Red Hat Test Certificate' -i /usr/share/shim/shim.efi \ > -o /boot/efi/EFI/fedora/shim-rhtest-pesign104.efi -s It works. The problems in comment 6 are rooted in PEBKAC; my key enrollment scheme was the culprit: > (2) As usual I extracted the RH test certificate and test CA certificate > from the pesign package as I wrote in > <http://www.linux-kvm.org/page/OVMF#Confirmation_of_secure_boot_in_Fedora_18>, > with something like > > certutil -L -d f18-keys/ -n 'Red Hat Test CA' -r \ > >'RedHatTestCA'.der > > certutil -L -d f18-keys/ -n 'Red Hat Test Certificate' -r \ > >RedHatTestCertificate.der > > [...] > > > (3) I enrolled these in OVMF as PK and KEK, respectively, plus the latter > one also in DB. Agan, to emphasize what I tried in comment 6: RedHatTestCA -> PK RedHatTestCertificate -> KEK RedHatTestCertificate -> DB This doesn't work with current OVMF, but another enrollment scheme works. The shim binary that had been signed by an earlier pesign build, and originally installed by Anaconda for my F19 Alpha TC5 VM, continues to be refused under "that other" enrollment, but "shim-unsigned" re-signed with pesign-0.104-1.fc19 as described above does work under "that other" enrollment. [root@ovmf-f19-a ~]# dmesg | grep -i secure [ 0.000000] Secure boot enabled **** PAST **** My only excuse for trying such an enrollment is that when I tested Fedora 18, it *did* work. See bullet 6 under the linux-kvm.org link quoted above: > 6. I started the guest. > > * As soon as the TianoCore splash screen showed, I entered the setup menu > and selected Device Manager | Secure Boot Options, > * enrolled RedHatTestCA.der as PK. > * enrolled RedHatTestCertificate.der as one KEK and one DB entry, > [...] This was consistent with my working idea of the keys and databases: +---[ OPINION ]---[ OPINION ]---[ OPINION ]---[ OPINION ]---[ OPINION ]----+ | | | PK (platform key): | | - single key | | - X509 format | | - does not sign binaries | | - signs KEK updates | | | | KEK (key exchange key): | | - several keys with equal rank, | | - each is in X509 or RSA2048 format, | | - each can sign an EFI binary, | | - each can sign a DB update, | | - each can sign a DBX update | | | | DB (accepted signatures adatabase): | | - several keys, signatures and hashes, | | - a key can sign an EFI binary (ie. if a binary is signed with this key, | | and the signature is valid, the binary is accepted), | | - a signature can accept an EFI binary (ie. if a binary comes with this | | exact signature, it is accepted), | | - a hash can accept an *unsigned* EFI binary if it matches the hash. | | | | DBX (forbidden signatures database): | | - overrides any acceptance by KEK or DB, | | - several keys, signatures and hashes that mirror DB concepts: | | - revoked signing keys for EFI binaries, | | - revoked signatures of EFI binaries, | | - denied hashes of unsigned EFI binaries. | | | +---[ OPINION ]---[ OPINION ]---[ OPINION ]---[ OPINION ]---[ OPINION ]----+ RedHatTestCertificate (a self-signed association of the name RedHatTestCertificate and a public key) was confirmed (= also signed) by RedHatTestCA. RedHatTestCA was accepted as root of trust. This used to map well to the following enrollment: RedHatTestCA -> PK RedHatTestCertificate -> KEK RedHatTestCertificate -> DB RedHatTestCA was PK. RedHatTestCA also signed RedHatTestCertificate. Since PK can authenticate KEK updates, this allowed enrolling RedHatTestCertificate as KEK. RedHatTestCertificate was self-signed. IOW RedHatTestCertificate (in KEK role) signed RedHatTestCertificate (in DB entry role). This allowed RedHatTestCertificate to be enrolled as DB entry. The shim binary for F18 was signed (as far as I remember) with RedHatTestCertificate. RedHatTestCertificate had been enrolled both as KEK and as a DB entry (see above). In each one of those roles RedHatTestCertificate worked as an EFI binary signing key. Therefore F18 shim was accepted. **** PRESENT **** Something has changed, maybe with edk2 SVN r14141. Either the key / database roles, or the way "pesign" signs "shim" now (see the "sbverify" section of comment 6). The past enrollment stopped to work. The following enrollment does work however: RedHatTestCA -> PK <nothing> -> KEK RedHatTestCA -> DB I ended up with this enrollment after adding a heap of debug code to edk2's image verification. In one sentence, for a signed EFI binary, a signing key entry in DB must be the *absolute root* certificate of the binary's signature chain. So, although in step (4) -- see at the top -- I signed shim with 'Red Hat Test Certificate' and *not* 'Red Hat Test CA', I must put the *latter* in DB. Confirming a middle link in the signature chain with a DB signing key is insufficient. (BTW this also holds for sbverify; from comment 6: > FWIW, if I convert the test *CA* cert to PEM format too (see the x509 > command in step (5)), then sbverify accepts both images: > > ../sbverify --verbose --cert RedHatTestCA.pem \ > /boot/efi/EFI/fedora/shim-rhtest-pesign104.efi ) ... Actually, yes, this has changed precisely with edk2 SVN r14141, according to the following comment: <https://github.com/tianocore/edk2/commit/6de4c35f#L0L1014> So, this bug is fixed. Thank you.
For posterity I'll attach my debug patch and save here its output too. **** When attempting to boot the original F19 Alpha TC5 shim.efi binary (the signed one, from shim-0.2-3.fc18) under the "new" enrollment scheme from comment 9, the debug patch produces the following output (slightly edited to save space): [starting up] DxeImageVerificationHandler: entry FileSize=1370230 BootPolicy=1 File=PciRoot(0x0)/Pci(0x4,0x0)/ HD(1,GPT,7623C01C-A240-417A-8B21-0925DFD15142,0x800,0x64000)/ \EFI\fedora\shim.efi IMAGE_FROM_FIXED_MEDIA Policy == 5 DOS header present PE/COFF header at 0x00000080 magic 0x020B NumberOfRvaAndSizes=16 SecDataDir=3C935140 signed image, SecDataDir VirtualAddress=0x0014C1A0 Size=0x000026D6 [attempting to verify first signature] OffSet=0x0014C1A0 CertLen=0x00002150 AuthData=3CA811C0 AuthDataSize=0x00002148 HashPeImageByType: digest algorithm: SHA256 image digest: 78:B4:ED:CA:AB:C8:D9:09:3E:20:E2:17:80:2C:AE:B4: F0:9E:23:A3:39:4C:4A:CC:6E:87:E8:F3:53:95:31:0F IsPkcsSignedDataVerifiedBySignatureList: Cert=3CB06034 CertCount=1 AuthenticodeVerify: hash in signature: 78:B4:ED:CA:AB:C8:D9:09:3E:20:E2:17:80:2C:AE:B4: F0:9E:23:A3:39:4C:4A:CC:6E:87:E8:F3:53:95:31:0F matched hash IsPkcsSignedDataVerifiedBySignatureList: 0: AuthenticodeVerify(): 0 DxeImageVerificationHandler: digest NOT signed by accepted certificate digest NOT found in DBX digest NOT found in DB [verification of first signature failed, trying 2nd] OffSet=0x0014E2F0 CertLen=0x00000586 AuthData=3CA83310 AuthDataSize=0x0000057E HashPeImageByType: digest algorithm: SHA256 image digest: 78:B4:ED:CA:AB:C8:D9:09:3E:20:E2:17:80:2C:AE:B4: F0:9E:23:A3:39:4C:4A:CC:6E:87:E8:F3:53:95:31:0F IsPkcsSignedDataVerifiedBySignatureList: Cert=3CB06034 CertCount=1 AuthenticodeVerify: hash in signature: 78:B4:ED:CA:AB:C8:D9:09:3E:20:E2:17:80:2C:AE:B4: F0:9E:23:A3:39:4C:4A:CC:6E:87:E8:F3:53:95:31:0F matched hash IsPkcsSignedDataVerifiedBySignatureList: 0: AuthenticodeVerify(): 0 DxeImageVerificationHandler: digest NOT signed by accepted certificate digest NOT found in DBX digest NOT found in DB [verification of 2nd signature failed too] SecDataDir contents corrupt [this message bears witness to the incorrect signature alignment] verification failed exit: 0000001A [code for EFI_SECURITY_VIOLATION] **** Booting the correctly re-signed shim binary under the "new" enrollment scheme from comment 9: [starting up] DxeImageVerificationHandler: entry FileSize=1363120 BootPolicy=1 File=PciRoot(0x0)/Pci(0x4,0x0)/ HD(1,GPT,7623C01C-A240-417A-8B21-0925DFD15142,0x800,0x64000)/ \EFI\fedora\shim-oldgnuefi-rhtest-pesign104.efi IMAGE_FROM_FIXED_MEDIA Policy == 5 DOS header present PE/COFF header at 0x00000080 magic 0x020B NumberOfRvaAndSizes=16 SecDataDir=3C934140 signed image, SecDataDir VirtualAddress=0x0014C1A0 Size=0x00000B10 [attempting to verify first signature] OffSet=0x0014C1A0 CertLen=0x00000B10 AuthData=3CA801C0 AuthDataSize=0x00000B08 HashPeImageByType: digest algorithm: SHA256 image digest: 78:B4:ED:CA:AB:C8:D9:09:3E:20:E2:17:80:2C:AE:B4: F0:9E:23:A3:39:4C:4A:CC:6E:87:E8:F3:53:95:31:0F IsPkcsSignedDataVerifiedBySignatureList: Cert=3CB06034 CertCount=1 AuthenticodeVerify: hash in signature: 78:B4:ED:CA:AB:C8:D9:09:3E:20:E2:17:80:2C:AE:B4: F0:9E:23:A3:39:4C:4A:CC:6E:87:E8:F3:53:95:31:0F matched hash IsPkcsSignedDataVerifiedBySignatureList: 0: AuthenticodeVerify(): 1 DxeImageVerificationHandler: digest signed by accepted certificate digest NOT found in DBX verification successful
Created attachment 750775 [details] [1/2] DxeImageVerificationLib + AuthenticodeVerify(): strip whitespace .../Library/BaseCryptLib/Pk/CryptAuthenticode.c | 2 +- .../DxeImageVerificationLib.c | 38 ++++++++++---------- .../DxeImageVerificationLib.inf | 8 ++-- 3 files changed, 24 insertions(+), 24 deletions(-)
Created attachment 750776 [details] [2/2] bunch of debug messages for OVMF signature verification - DxeImageVerificationHandler() - HashPeImageByType() - IsPkcsSignedDataVerifiedBySignatureList() - AuthenticodeVerify() --- .../Library/BaseCryptLib/Pk/CryptAuthenticode.c | 10 ++ .../DxeImageVerificationLib.c | 112 +++++++++++++++++++- .../DxeImageVerificationLib.inf | 1 + 3 files changed, 119 insertions(+), 4 deletions(-)
pesign-0.106-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/pesign-0.106-1.el6
pesign-0.106-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
pesign-0.106-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/pesign-0.106-1.fc19
shim-signed-0.2-4.4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/shim-signed-0.2-4.4.fc19
(In reply to Laszlo Ersek from comment #9) > ... Actually, yes, this has changed precisely with edk2 SVN r14141, > according to the following comment: > > <https://github.com/tianocore/edk2/commit/6de4c35f#L0L1014> > > So, this bug is fixed. Thank you. Any chance I can get you to test https://admin.fedoraproject.org/updates/shim-signed-0.2-4.4.fc19 ? This should include a working shim with both signatures. It works locally here, but obviously I'd prefer more testing (and karma) on the update than just my own :)
I yum-erased all shim packages from my earlier OVMF guest, and manually deleted all remaining ad-hoc shim binaries from under /boot/efi/EFI/fedora. Then I ran "yum update", and finally installed "shim-signed-0.2-4.4.fc19" from <http://koji.fedoraproject.org/koji/buildinfo?buildID=423244>. "shim-0.2-4.4.fc19.x86_64" from the above Koji URL pulls in "shim-unsigned-0.2-3.fc18.x86_64" again as a dependency. The following two files show up in the EFI system partition (from the former package): 77 1332 -rwx------ 1 root root 1362696 May 31 19:38 /boot/efi/EFI/fedora/shim-fedora.efi 78 1340 -rwx------ 1 root root 1371224 May 31 19:38 /boot/efi/EFI/fedora/shim.efi (md5sums: a692164fad939eb2c05a9c9360f3c82f /boot/efi/EFI/fedora/shim-fedora.efi c7734212b5ac0c20a76e4894c6333316 /boot/efi/EFI/fedora/shim.efi ) According to pesign --show-signature and sbverify, the first file (shim-fedora.efi) has apparently been signed with the real Fedora Secure Boot Signer (one signature only), while the second file (shim.efi) has signatures from both Fedora Secure Boot Signer and Microsoft Windows UEFI Driver Publisher. From the F18 UEFI Secure Boot Guide, section 3.1 Keys, the Fedora Secure Boot Signer pubkey is available in the shim source package. Indeed, I found it from "shim-0.2-3.fc18.src.rpm": openssl x509 -inform DER -outform PEM \ -in ~/rpmbuild/SOURCES/fedora-ca.cer -out FedoraSecureBootSigner.pem This pubkey accepts the "shim-fedora.efi" binary: ../sbsigntools-951ee95a/sbverify --verbose \ --cert FedoraSecureBootSigner.pem \ /boot/efi/EFI/fedora/shim-fedora.efi warning: data remaining[1237352 vs 1362696]: gaps between PE/COFF sections? image signature issuers: - /CN=Fedora Secure Boot CA image signature certificates: - subject: /CN=Fedora Secure Boot Signer issuer: /CN=Fedora Secure Boot CA - subject: /CN=Fedora Secure Boot CA issuer: /CN=Fedora Secure Boot CA certificate store: - subject: /CN=Fedora Secure Boot CA issuer: /CN=Fedora Secure Boot CA Signature verification OK The same pubkey should accept "shim.efi" too (it being signed with both the Fedora key and the Microsoft key). sbverify fails to verify the Fedora signature on "shim.efi", but I think that's because the Microsoft signature comes first, and sbverify bails out there. Let's see if I can check the Microsoft signature on "shim.efi" using the keys from James Bottomley's blog post <http://blog.hansenpartnership.com/the-microsoft-keys/>: for C in db.0 db.1 db.2 kek pk; do openssl x509 -inform DER -outform PEM -in $C.cer -out $C.pem if ../sbsigntools-951ee95a/sbverify \ --cert $C.pem /boot/efi/EFI/fedora/shim.efi >/dev/null 2>&1; then printf 'matching pubkey: %s\n' "$C" fi done matching pubkey: db.1 (Which is "CN=Microsoft Corporation UEFI CA 2011".) This provides us with the following three test cases for OVMF secure boot: - enrolling "fedora-ca.cer" as PK and as one DB entry should accept (a) both "shim-fedora.efi" (b) and "shim.efi", and boot F19 in SB mode using either shim binary, - enrolling "db.1.cer" as PK and as one DB entry should accept (c) "shim.efi" and boot F19 in SB mode. (a) PASS: Binary is whitelisted [ 0.000000] Secure boot enabled [ 0.437153] EFI: Loaded cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to '.system_keyring' (b) PASS: Binary is whitelisted [ 0.000000] Secure boot enabled [ 0.453967] EFI: Loaded cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to '.system_keyring' (c) PASS: Binary is verified by the vendor certificate [ 0.000000] Secure boot enabled
Sorry, in comment 18 I forgot to save the following under case (c): [ 0.456325] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' linked to '.system_keyring'
(In reply to Peter Jones from comment #17) > Any chance I can get you to test > https://admin.fedoraproject.org/updates/shim-signed-0.2-4.4.fc19 ? This > should include a working shim with both signatures. It works locally here, > but obviously I'd prefer more testing (and karma) on the update than just my > own :) Dished out some karma. Please let me know if there's anything else to test.
Package shim-signed-0.2-4.4.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing shim-signed-0.2-4.4.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9816/shim-signed-0.2-4.4.fc19 then log in and leave karma (feedback).
pesign-0.106-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
shim-signed-0.2-4.4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/shim-signed-0.2-4.4.fc18
shim-signed-0.2-4.4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
shim-signed-0.2-4.4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.