UEFI Secure Boot - GRUB WIP report

[Luca Boccassi]

On Wed, 2018-06-20 at 14:12 +0200, Philipp Hahn wrote:
> Hello Luca,
> 
> Am 19.06.2018 um 16:38 schrieb Luca Boccassi:
> > On Tue, 2018-06-19 at 11:00 +0200, Philipp Hahn wrote:
> > > Am 19.06.2018 um 10:25 schrieb Colin Watson:
> > > The good news: It works: It loads the signed SHIM and GRUB.
> > > 
> > > The bad news: GRUB still falls back to loading an unsigned Linux
> > > kernel.
> > > I suspect
> > > <https://salsa.debian.org/pmhahn/grub/commit/448311e7374076fbd53e
> > > 4c8b
> > > 0f92accd04e07920>
> > > @Luca: Any idea?
> > 
> > Strange - I have tested running with that patch for a long time,
> > and it
> > does fail to load if the kernel is not signed with an expected key.
> > Just tried again to confirm, and it's still the case, as far as I
> > can
> > see.
> > 
> > I really can't find my way around git-dpm though, I find it a bit
> > confusing, being used to gbp - could there be an issue with the
> > quilt
> > patch?
> 
> I'm haven't yet used git-dpm, too.
> 
> > I have attached the debdiff of the grub build I use, here's the
> > .debian.tar.xz:
> > 
> > https://download.opensuse.org/repositories/home:/bluca:/debian_secu
> > re_boot/Debian9/grub2_2.02+dfsg1-5.1.debian.tar.xz
> > 
> > Any chance a fully built image could be uploaded $somewhere to
> > test?
> > Otherwise I'll try to build one with your script as soon as I have
> > a
> > moment.
> 
> I uploaded my files to
> <http://updates.software-univention.de/download/secure-boot/>

Ok, thanks, I will have a play with them look later today or tomorrow

> > I use OBS to build&sign everything, if you want to check what I run
> > here's a live-bootable ISO without a signed kernel that fails to
> > boot
> > and goes back to grub after printing "error: /live/$FOO has invalid
> > signature.":
> 
> 
> I manually edited the GRUB menu entry and tried all 4 cases
>   linux{,efi} vmlinuz-4.16.0-2-amd64{,.efi.signed}
> 
> - 3 load but afterwards I don't get /sys/kernel/security/securelevel
> and
> Linux Kernel prints:
> >   EFI stub: UEFI Secure Boot is enabled.
> >   secureboot: Secure boot could not be determined (mode 0)

This is exactly the symptom fixed by this PR (EFI variable is set so
you get the first print, but grub overwrites it so the kernel can't
determine the mode anymore):

https://salsa.debian.org/pmhahn/grub/merge_requests/1

So 2 out of 2 changes seemingly not present in the built binary do
sound a bit suspicious :-)

> - Only "linuxefi" on "unsigned vmlinuz" fails es expected

Just tried with my images, and the one with an unsigned kernel fails
with both "linux" and "linuxefi".

Curiously the signed one fails with linuxefi but with a completely
different problem unrelated to secure boot, but I'm 99% sure it's due
to how we build the image with live-build, I'll have a look when I have
time.

> > https://download.opensuse.org/repositories/home:/bluca:/debian_secu
> > re_boot/img_nokernel/iso/standard_20180619T1255-amd64-
> > Build37.1.hybrid.iso
> > 
> > Here's one with a signed kernel that boots fine and shows "Kernel
> > is
> > locked down from EFI secure boot" in the kernel log:
> > 
> > https://download.opensuse.org/repositories/home:/bluca:/debian_secu
> > re_boot/img/iso/standard_20180611T1201-amd64-Build37.17.hybrid.iso
> > 
> > To get the certificate to load in qemu:
> > 
> > wget https://build.opensuse.org/projects/home:bluca:debian_secure_b
> > oot/ssl_certificate -O- | openssl x509 -inform pem -outform der
> > -out obs.der
> 
> I'll take a look later - thanks for looking into it.
> ...
> 
> > Incidentally, any chance the couple of commits that you merged
> > yesterday into your signing branch could be included as well? Would
> > you
> > like me to re-send the MRs to the new branch?
> 
> I already cherry-picked them into my new branch, but I forgot to push
> them :-( I've done that now.
> 
> Philipp

No worries - and sorry to be a pain again, but the vendor metadata
commit is still missing ( 10547b50b7a2f55 ) :-)

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20180620/64f714f4/attachment.sig>