RE: Updating shim for buster
> -----Original Message-----
> From: Steve McIntyre <steve@einval.com>
> Sent: Wednesday, January 16, 2019 11:04 AM
> To: debian-efi@lists.debian.org
> Subject: Re: Updating shim for buster
>
>
> [EXTERNAL EMAIL]
>
> Hi Luca, and thanks for starting this thread!
>
> On Wed, Jan 16, 2019 at 04:38:30PM +0000, Luca Boccassi wrote:
> >
> >Should shim be updated before buster ships? The current version is
> >quite old.
>
> Nod. I've discussed this with upstream EFI/shim folks and they'd
> really like us to move forwards from the ancient version we're
> currently using. With the new process for shim review, I'm hoping we
> shouldn't have any problems getting this reviewed and signed before
> buster.
>
> We should also expand our architecture coverage. At the moment we only
> have shim-signed for amd64. We should also get signatures for i386 and
> arm64.
>
> >If the answer is yes, I would recommend going to v15 and to backport
> >the following 2 commits:
> >
> >https://github.com/rhboot/shim/commit/a625fa5
> >https://github.com/rhboot/shim/commit/e563bc3
> >
> >Version 14, which is currently in Salsa, has a bug where in case of
> >chainloading shim -> grub -> shim -> grub the protocol is not in sync
> >with the systab, so exit_boot_services returns an EFI security
> >violation even if everything has been verified correctly. This is fixed
> >in v15.
> >
> >The two commits above further fix a bootloop when a user launches shim
> >manually from the EFI shell, from a relative path.
> >
> >I have verified that v15 + the above 2 commits works fine on TianoCore,
> >on my Dell laptop, on an AMI UEFI implementation I have on a Supermicro
> >board, and on a third-party proprietary UEFI implementation we have at
> >$work using a live-build ISO I built and self-signed.
> >
> >The following also needs backporting simply to fix the build, as
> >upstream decided to always run "git clean" on "make clean" which works
> >as well as you can imagine on a buildd...
> >
> >https://github.com/rhboot/shim/pull/163
>
> ACK. Thanks for the pointers!
>
If you're going to be re-spinning shim, before deciding to take well known
snapshot plus random commits, I'd recommend pinging shim team and asking
them if they can tag a new release for you instead.
At least in terms of matching behavior of any future bugs that arise it should
be easier to work with upstream and report issues or compare to other distros
if there is a well known version to match up to.
Reply to: