sbsigntool fix (was Re: [PATCH] Fix PE/COFF checksum calculation)

James Bottomley James.Bottomley at HansenPartnership.com
Sat Jul 27 23:22:37 BST 2019


On Sat, 2019-07-27 at 23:09 +0100, Steve McIntyre wrote:
> On Sat, Jul 27, 2019 at 02:40:08PM -0700, James Bottomley wrote:
> > On Sat, 2019-07-27 at 00:23 +0100, Steve McIntyre wrote:
> 
> ...
> 
> > > In the Debian shim-signed package build, we use sbattach to
> > > remove
> > > then re-attach the Microsoft signature on the binary that they
> > > signed
> > > for us, to validate 100% that there are no changes. This code was
> > > even
> > > written by Steve Langasek! See
> > > 
> > >   https://salsa.debian.org/efi-team/shim-signed/blob/master/Makef
> > > ile
> > > 
> > > for what we're doing.
> > > 
> > > We used to use sbsigntool 0.6 and this worked fine. It broke
> > > after we
> > > updated to 0.9.2 in Debian - I could not get the checksums to
> > > match
> > > again, so I worked through the code and found what looked like a
> > > bug. Checking the log on that commit, I also see:
> > > 
> > >     [jejb: add endian to autogen.sh and fix for multi-sign]
> > 
> > OK, this might be it.  Before the addition of multiple signatures,
> > the
> > sigbuf only contained the signature, not the struct
> > _WINH_CERTIFICATE
> > header, which would mean if the checksum is supposed to be updated
> > over
> > the entire certificate table then we'd have to sum the header and
> > the
> > signature separately.  After the multiple certificate support,
> > there's
> > not much difference between cert_table and sigbuf because now they
> > always both contain the header and signature otherwise the code
> > couldn't iterate over multiple signatures (it needs the information
> > from the header to say where the next signature begins).
> > 
> > So I think this means your patch is correct because the header(s)
> > are
> > now included in the sum over sigbuf.
> 
> ACK.
> 
> If you're going to take the patch, could I also give you a friendly
> prod to update the README too? :-)

Well, the README is simple historical information and Canonical hasn't
taken down the historical repository (yes, I suppose).

> Also, for information in case you're interested - the efi list we've
> been including in CC is a new list I created quite recently, to try
> and host some shared discussion and patch reviews for the EFI
> userland
> tools. We have a few people signed up so far (Peter, Ard, etc.).
> Please feel free to join us!
> 
>   https://lists.einval.com/cgi-bin/mailman/listinfo/efi

Sure, although I'll probably just read it over the archive interface.

Regards,

James




More information about the Efi mailing list