Bug 963361 - pesign currently does not align signature list entries, which will cause shim to fail on newer firmware.
pesign currently does not align signature list entries, which will cause shim...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: shim-signed (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
RejectedBlocker AcceptedFreezeException
: Reopened
Depends On:
Blocks: F19Beta-accepted/F19BetaFreezeException
  Show dependency treegraph
 
Reported: 2013-05-15 13:46 EDT by Peter Jones
Modified: 2013-06-19 00:33 EDT (History)
8 users (show)

See Also:
Fixed In Version: shim-signed-0.2-4.4.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-11 23:33:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
shim binaries re-signed with (a) pesign-0.104-1.fc19, (b) sbsign/951ee95a (318.26 KB, application/x-xz)
2013-05-19 19:39 EDT, Laszlo Ersek
no flags Details
shim-0.2-3 rebuilt with gnu-efi-3.0s-2.fc19, and signed with pesign-0.104-1.fc19 / sbsign-951ee95a (314.75 KB, application/x-xz)
2013-05-20 04:34 EDT, Laszlo Ersek
no flags Details
[1/2] DxeImageVerificationLib + AuthenticodeVerify(): strip whitespace (8.15 KB, patch)
2013-05-20 21:15 EDT, Laszlo Ersek
no flags Details | Diff
[2/2] bunch of debug messages for OVMF signature verification (14.76 KB, patch)
2013-05-20 21:15 EDT, Laszlo Ersek
no flags Details | Diff

  None (edit)
Description Peter Jones 2013-05-15 13:46:10 EDT
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.
Comment 1 Adam Williamson 2013-05-15 13:54:34 EDT
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.
Comment 2 Jóhann B. Guðmundsson 2013-05-15 17:04:12 EDT
This only affects the latest and greatest hardware out there right +1 FE -1. 

Workaround users can always disable secure boot
Comment 3 Jóhann B. Guðmundsson 2013-05-15 17:04:38 EDT
-1 Beta blocker that is
Comment 4 Jaroslav Reznik 2013-05-16 04:09:40 EDT
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?
Comment 5 Adam Williamson 2013-05-16 17:36:11 EDT
There are enough +1 FE votes to mark this acceptedFE, so I'll do that at least. Blocker status is still undecided.
Comment 6 Laszlo Ersek 2013-05-19 19:39:45 EDT
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
Comment 7 Laszlo Ersek 2013-05-20 04:34:43 EDT
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
Comment 8 Adam Williamson 2013-05-20 12:51:27 EDT
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.
Comment 9 Laszlo Ersek 2013-05-20 20:08:53 EDT
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.
Comment 10 Laszlo Ersek 2013-05-20 20:55:04 EDT
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
Comment 11 Laszlo Ersek 2013-05-20 21:15:08 EDT
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(-)
Comment 12 Laszlo Ersek 2013-05-20 21:15:34 EDT
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(-)
Comment 13 Fedora Update System 2013-05-21 15:43:49 EDT
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
Comment 14 Fedora Update System 2013-05-22 17:38:58 EDT
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.
Comment 15 Fedora Update System 2013-05-30 08:44:22 EDT
pesign-0.106-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/pesign-0.106-1.fc19
Comment 16 Fedora Update System 2013-05-31 13:47:20 EDT
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
Comment 17 Peter Jones 2013-05-31 14:07:34 EDT
(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 :)
Comment 18 Laszlo Ersek 2013-05-31 19:10:25 EDT
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
Comment 19 Laszlo Ersek 2013-05-31 19:14:39 EDT
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'
Comment 20 Laszlo Ersek 2013-05-31 19:21:09 EDT
(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.
Comment 21 Fedora Update System 2013-06-01 13:51:42 EDT
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).
Comment 22 Fedora Update System 2013-06-07 23:38:31 EDT
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.
Comment 23 Fedora Update System 2013-06-10 11:34:50 EDT
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
Comment 24 Fedora Update System 2013-06-11 23:33:43 EDT
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.
Comment 25 Fedora Update System 2013-06-19 00:33:41 EDT
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.

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