Page 1 of 2

Re: Debian gains Secure Boot support in sid

Posted: 2016-07-19 21:11
by Head_on_a_Stick
tomazzi wrote:I would try an alternative EFI boot manager, like rEFInd
I installed refind and ran `refind-install`

The system starts fine and shows a (working) rEFInd menu but fails to start with Secure Boot enabled.
:(

Re: Debian gains Secure Boot support in sid

Posted: 2016-07-19 21:24
by tomazzi
Head_on_a_Stick wrote:I already use btrfs:
Nope, As You said (in previous posts), You've copied the kernel image to the EFI partition?? - or am I missing something?
Head_on_a_Stick wrote:I installed refind and ran `refind-install`
The system starts fine and shows a (working) rEFInd menu but fails to start with Secure Boot enabled.
This is a bit strange...

First 2 things I would check is to:
a) fsck the EFI partition
b) compare copies of files in the EFI partition with originals, f.e. using 'cmp' command (bit by bit)

Regards.

Re: Debian gains Secure Boot support in sid

Posted: 2016-07-19 21:31
by Head_on_a_Stick
tomazzi wrote:
Head_on_a_Stick wrote:I already use btrfs:
Nope, As You said (in previous posts), You've copied the kernel image to the EFI partition?? - or am I missing something?
Are you confused?

The EFI system partition *must* be FAT-formatted.

UEFI firmware cannot read any other filesystem.

My ESP is FAT32 but my root partition is btrfs.
a) fsck the EFI partition
b) compare copies of files in the EFI partition with originals, f.e. using 'cmp' command (bit by bit)
What would this accomplish? Anyway, systemd has already fsck'd the ESP :mrgreen:

The Debian kernel images that I have copied to the ESP boot just fine with Secure Boot disabled so clearly there is no corruption.

In fact, I have just installed the RC kernel from experimental and my kernel post-install script copied the fresh images over automatically.

This new kernel image boots just fine so I will now try a reboot in Secure mode with this NVRAM configuration:

Code: Select all

root@sid:~# efibootmgr -v
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0001,0000,0006,0007,0005
Boot0000* Debian sid    HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\sid\vmlinuz)r.o.o.t.=./.d.e.v./.s.d.a.3. .r.o.o.t.f.l.a.g.s.=.s.u.b.v.o.l.=.s.i.d. .r.w. .q.u.i.e.t. .z.s.w.a.p...e.n.a.b.l.e.d.=.1. .e.l.e.v.a.t.o.r.=.n.o.o.p. .i.n.i.t.r.d.=./.s.i.d./.i.n.i.t.r.d...i.m.g.
Boot0001* rEFInd Boot Manager   HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\EFI\refind\refind_x64.efi)
Boot0005* UEFI OS       VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0006* UEFI OS       HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0007* ubuntu        HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\EFI\Ubuntu\grubx64.efi)
Back in a mo'...

EDIT: No, the RC kernel from experimental doesn't work with EFI_STUB booting and Secure Boot enabled either.
:(

Re: Debian gains Secure Boot support in sid

Posted: 2016-07-19 22:00
by tomazzi
Head_on_a_Stick wrote:Are you confused?
I think I'm not...
Head_on_a_Stick wrote:The EFI system partition *must* be FAT-formatted.
UEFI firmware cannot read any other filesystem.
Correct - the UEFI firmware can't read "any other filesystem", but rEFInd can - and btrfs is supported in read-only mode.
Head_on_a_Stick wrote:The Debian kernel images that I have copied to the ESP boot just fine with Secure Boot disabled so clearly there is no corruption.
Nope, this doesn't mean anything - even slightly modified image can be still able to boot, but it won't pass the checksum verification.
Head_on_a_Stick wrote:What would this accomplish? Anyway, systemd has already fsck'd the ESP
fsck is simply not checking the correctness of the files - it's just checking consistency of the file system - those are 2 different things.

Regards.

Re: Debian gains Secure Boot support in sid

Posted: 2016-07-20 07:00
by Head_on_a_Stick
tomazzi wrote:
Head_on_a_Stick wrote:The EFI system partition *must* be FAT-formatted.
UEFI firmware cannot read any other filesystem.
Correct - the UEFI firmware can't read "any other filesystem", but rEFInd can - and btrfs is supported in read-only mode.
I'm sorry, I don't understand what you mean here.

Clearly I have to learn more about rEFInd so thanks for the heads-up.

An update from my end: the Ubuntu GRUB-signed package is dependent on secureboot-db which pulls in sbsigntool which is utility to sign and manage .efi loaders.

These packages do not exist in Debian (yet) but they do have an equivalent in Arch:
https://www.archlinux.org/packages/extr ... /efitools/

I will try signing the Debian GRUB .efi loader and updating the key DB on my motherboard using the tools provided by Arch and report back...

Re: Debian gains Secure Boot support in sid

Posted: 2016-07-20 11:09
by tomazzi
Head_on_a_Stick wrote:
tomazzi wrote:
Head_on_a_Stick wrote:The EFI system partition *must* be FAT-formatted.
UEFI firmware cannot read any other filesystem.
Correct - the UEFI firmware can't read "any other filesystem", but rEFInd can - and btrfs is supported in read-only mode.
I'm sorry, I don't understand what you mean here.
I'm talking about the possibility to boot the kernel directly off the btrfs partition.

This could be important factor, because UEFI has tons of bugs, and one of them is really interesting:
http://www.rodsbooks.com/refind/drivers.html
To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently somewhat limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with EFI stub loader support from booting from the ESP of at least some Macs.
I suppose that one of trivial reasons for this bug can be that the kernel image file (or in fact any other file) has different physical representation under FAT and other filesystems, so buggy UEFI firmware has a lot of space for generating various errors, starting from wrong alignment of the image data in the memory (what will cause EFI loader to crash), ending up with wrong calculation of the file checksum -> SecureBoot will fail.

But I'm just guessing here.

Regards.

Re: Debian gains Secure Boot support in sid

Posted: 2016-07-23 13:29
by Head_on_a_Stick
Head_on_a_Stick wrote:I will try signing the Debian GRUB .efi loader and updating the key DB on my motherboard using the tools provided by Arch and report back...
Interesting result when I tried to sign the Debian sid kernel image with my (self-generated) keys:

Code: Select all

empty@Arch ~ % sudo sbsign --key db.key --cert db.crt /boot/sid/vmlinuz
Image was already signed; adding additional signature
I am now mounting /boot/efi in Debian to the ESP so that the kernel images are unpacked by APT directly.

EDIT: It seems that the Secure Boot implementation on my MB is b0rked, I will have to try different hardware.

Re: Debian gains Secure Boot support in sid

Posted: 2016-08-11 14:13
by tuxserbia
Head_on_a_Stick wrote:
Head_on_a_Stick wrote:
EDIT: It seems that the Secure Boot implementation on my MB is b0rked, I will have to try different hardware.

It seems to me lots of MBs are broken

https://rol.im/securegoldenkeyboot/

;-)

Re: Debian gains Secure Boot support in sid

Posted: 2016-08-11 23:02
by phenest
tomazzi wrote:This could be important factor, because UEFI has tons of bugs, and one of them is really interesting:
http://www.rodsbooks.com/refind/drivers.html
To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently somewhat limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with EFI stub loader support from booting from the ESP of at least some Macs.
I read somewhere that Macs don't use the ESP for booting. The ESP is there but used as a staging area for firmware updates instead. So it's not a bug, but Apple's alternative implementation of UEFI, I guess.

Re: Debian gains Secure Boot support in sid

Posted: 2016-08-20 20:52
by tomazzi
phenest wrote:Apple's alternative implementation of UEFI
There's no such thing as an "alternative" implementation - the standard is clear. If Apple would implement "a bad/unexpected behaviour", then it's simply no longer a "secure boot" - it's "something else" - an unspecified proprietary "solution"...

Regards.