Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Debian gains Secure Boot support in sid

User discussion about Debian Development, Debian Project News and Announcements. Not for support questions.
Message
Author
User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Debian gains Secure Boot support in sid

#16 Post 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.
:(
deadbang

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Debian gains Secure Boot support in sid

#17 Post 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.
Odi profanum vulgus

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Debian gains Secure Boot support in sid

#18 Post 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.
:(
deadbang

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Debian gains Secure Boot support in sid

#19 Post 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.
Odi profanum vulgus

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Debian gains Secure Boot support in sid

#20 Post 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...
deadbang

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Debian gains Secure Boot support in sid

#21 Post 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.
Odi profanum vulgus

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Debian gains Secure Boot support in sid

#22 Post 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.
deadbang

User avatar
tuxserbia
Posts: 46
Joined: 2015-07-31 13:10
Location: Italy
Contact:

Re: Debian gains Secure Boot support in sid

#23 Post 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/

;-)

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: Debian gains Secure Boot support in sid

#24 Post 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.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Debian gains Secure Boot support in sid

#25 Post 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.
Odi profanum vulgus

Post Reply