You are not logged in.

#1 2024-04-27 13:34:17

frieder
Member
Registered: 2020-08-25
Posts: 6

Am I misunderstanding how Secure Boot works or is my Laptop just weird

Hi,
I am able successfully boot into Arch with Secure Boot enabled.
However the method of achieving this seems to not match up with (my understanding of) the Wiki Article.
So in this post I'd like to discuss if I'm misunderstanding the Wiki Article, or if my Laptop behaves somehow out of the norm.

A: My understanding of how Secure Boot should work from https://wiki.archlinux.org/title/Unifie … oot_loader

1. Microsoft has 1-2 of their certificates enrolled on basically every UEFI motherboard
2. Only EFI files signed with the corresponding private keys are allwed to be executed when secure boot is enabled
3. Those efi files can then chainload other efi files
4. PreLoader and Shim have received signatures from Mircosoft, but only under the condition that they enforce some security policies themselves
5. That's why PreLoader and Shim have an allow list for efi files based on hashes and/or signatures
5.1 If one efi executable executes another efi executable, both executables have to be in the allow list.


But basically the entire setup boils down to installing a signed version of PreLoader or Shim and then enrolling the right keys in their respective lists.

B: How it works on my laptop  (Acer Aspire VN7-572G (V1.11))

1. My UEFI setup utility allows me to select up to 6 EFI files from any fat32 partition connected to the system "as trusted for executing"
1.1 These double as the boot entries, even when secure boot is disabled
1.2 Only .efi files can be selected , i.e.[EFISTUB](https://wiki.archlinux.org/title/EFISTUB) boot entries can not be created neither via the UEFI Setup nor via `efibootmgr`
1.3 There are no other restrictions on which efi files I can select as trusted
1.4 I have the suspicion that the verification is only path/ filename-based
2 These efi executables are only allowed to execute other efi executables that also have a "trusted for executing" boot entry


So the easiest way to boot into arch with secure boot enabled for me is the following:

1. Create a [unified kernel image](https://wiki.archlinux.org/title/Unified_kernel_image)
2. Select that uki as trusted in my UEFI setup, and move the corresponding boot entry to the top
Done.

C: If it is so easy, why am I even posting/ asking this

Firstly I am genuinely curious and would like to further my understanding of the secure boot process. There seems to be a discrepancy on how it works according to the wiki and how I see it working on my Laptop

But also I would like to use a boot loader to make dual booting with windows and switching to other kernels on reboot easier.

I tried setting up rEFInd +PreLoader with secure boot but this is how how far I came:
* I need to add trusted boot entries for PreLoader.efi, refind_x64.efi. and ext4_x64.efi, just to get into rEFInd without any errors
* I have three kernels installed (linux, linux-lts and linux-zen) if I need to add boot entries for each of them + the corresponding fallback initramfs I would need 9 boot entries just for arch. I have only 6 available
* Also since I'm dualbooting windows I would prefer to not have my initramfs in a partition that is writable by windows


Additional notes:

* When I first bought the Laptop in 2017 it actually shipped with Linpus-Linux

Offline

#2 2024-04-27 14:04:57

astralc
Member
Registered: 2022-09-17
Posts: 67

Re: Am I misunderstanding how Secure Boot works or is my Laptop just weird

1. I'm not sure how your laptop implement the secure boot override (MOK hashes?), but with shim (instead of PreLoader), you can use signatures, and sign refind and kernels. less hassle each update. Make sure to use shim-signed from aur.
2. You don't need to add hash/sign the entries in refind, only the kernels (not even the initramfs).
3. in case of preloader use (assuming you used preloader-signed), you only need one uefi entry (for the preloader) - and use the add hash to mok mechanism preloader have.

This assume the laptop implement secure boot correctly.

There is key "levels" in secure boot, starting with platform key, that used to verify. usually the PK of your machine is from the manufacture, and used to sign the MS (public) keys.
with sbctl you can implement your own key, but if you are already dual booting windows, I assume you don't want that.

Offline

#3 2024-04-27 14:11:49

frieder
Member
Registered: 2020-08-25
Posts: 6

Re: Am I misunderstanding how Secure Boot works or is my Laptop just weird

Thank you for your reply, I will try using shim-signed instead of preloader-signed, but I have already a remark:

>  in case of preloader use (assuming you used preloader-signed), you only need one uefi entry (for the preloader) - and use the add hash to mok mechanism preloader have.

That's exactly my point:
If I only add the ext4 driver to preloaders mok mechanism I am unable to use that driver.
Only when I additionally add an uefi entry for the ext4-driver, can I use it

This goes against common secure-boot wisdom, but it is what I observe

Offline

#4 2024-04-27 14:48:34

frieder
Member
Registered: 2020-08-25
Posts: 6

Re: Am I misunderstanding how Secure Boot works or is my Laptop just weird

Okay, nevermind my prior comment.

After using shim-signed and enrolling

refind_local.cer

to MoKList I was able to remove the ext4-driver uefi entry while retaining functionality.

I'm still a bit confused as to why the additional uefi boot entries were neccesary in the PreLoader case, and how my laptop's "trusted for executing" entries influence the MokList and vice versa.
Or why I am able to execute arbitrary efi files (without any signatures) with secure boot enabled, as long as I add a "trusted" boot entry.

Last edited by frieder (2024-04-27 15:01:08)

Offline

#5 2024-04-27 16:36:24

frieder
Member
Registered: 2020-08-25
Posts: 6

Re: Am I misunderstanding how Secure Boot works or is my Laptop just weird

I was curious what would happen if i used the not-signed version of shim. So I ran the refind script again, this time using the not-signed version of shim

refind-install --localkeys --shim /usr/share/shim/shimx64.efi

, added a trusted boot entry using the firmware and that worked without problems.

I  also checked with sbctl which keys are present on my Laptop and this is the result:

sbctl status

Installed:      ✓ sbctl is installed
Setup Mode:     ✓ Disabled
Secure Boot:    ✓ Enabled
Vendor Keys:    microsoft builtin-db builtin-db builtin-KEK builtin-PK

So my theory is that when I "select an UEFI file as trusted", it actually signs the efi file with a private key, stored somewhere in the firmware. Could that be it?

Offline

#6 2024-04-27 18:24:04

astralc
Member
Registered: 2022-09-17
Posts: 67

Re: Am I misunderstanding how Secure Boot works or is my Laptop just weird

it doesn't make sense for it to have vendor private key in the uefi, it sound like security issue (same key for acer every machine?).
"sbctl status" check if secure boot setting is activated in uefi, not if any binary is signed.

use "sbverify --list" (from sbsigntools) to check if specific binary is signed (and with which key).

Offline

#7 2024-04-27 20:32:55

frieder
Member
Registered: 2020-08-25
Posts: 6

Re: Am I misunderstanding how Secure Boot works or is my Laptop just weird

> it doesn't make sense for it to have vendor private key in the uefi, it sound like security issue (same key for acer every machine?).

What I was speculating (and now no longer believe) was: Every machine gets its own random key-pair, and the public key is signed with the vendors private key.
The private key lives somewhere on some firmware chip, while the public key is enrolled together with the vendor pubic key, and microsofts public keys

That is why I was trying to figure out which public keys are enrolled.


But you're right: To verify what I supposed I should check the binaries that I am booting.
The result:
No signature table present for
* /efi/EFI/Arch/arch-linux-lts.efi (The unified kernel image i am able to boot directly with secure boot enabled)
* /efi/EFI/refind/shimx64.efi (note that I switched from shim-signed to shim and am still able to boot with secure boot enabled)

Expectedly the refind and driver efi files each contain the locally generated rEFInd key.

I also checked the efi files the machine shipped with, since I still had a copy of them and this is the result

########/efi/efi_backup/EFI/BOOT/BOOTIA32.efi#######
signature 1
image signature issuers:
 - /C=Taiwan/ST=TW/L=Taipei/O=Acer/CN=Acer Root CA
image signature certificates:
 - subject: /C=Taiwan/ST=TW/L=Taipei/O=Acer/CN=Acer Database
   issuer:  /C=Taiwan/ST=TW/L=Taipei/O=Acer/CN=Acer Root CA
########/efi/efi_backup/EFI/BOOT/BOOTX64.efi#######
warning: data remaining[1229824 vs 1355416]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
########/efi/efi_backup/EFI/BOOT/fallback.efi#######
warning: gap in section table:
    .text   : 0x00000400 - 0x0001cc00,
    .reloc  : 0x0001cc39 - 0x0001ce40,
warning: gap in section table:
    .reloc  : 0x0001cc39 - 0x0001ce40,
    .data   : 0x0001d000 - 0x00031600,
gaps in the section table may result in different checksums
warning: data remaining[224637 vs 249118]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /CN=LINPUS
image signature certificates:
 - subject: /CN=LINPUS
   issuer:  /CN=LINPUS
########/efi/efi_backup/EFI/BOOT/grubx64.efi#######
No signature table present

Which shows some efi files containing the signature of the vendor, others by microsoft,


But this just leaves me with the same questions as before
* Why/ how am I able to just execute arbitrary efi files regardless of if they have a signature, as long as they have a boot entry?
* Why was rEFInd+PreLoader not able to use the ext4 driver untill I added the boot entry?

Last edited by frieder (2024-04-27 20:33:45)

Offline

Board footer

Powered by FluxBB