On Wed, 2019-01-16 at 17:12 +0000, Mario.Limonciello@dell.com wrote: > > -----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. Sure, that makes sense. Just wanted to highlight some annoying bugs that I encountered (and that Buster users will likely encounter too) and the solution for them. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part