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

frieder · 2024-04-27 13:34:17

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

astralc · 2024-04-27 14:04:57

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.

frieder · 2024-04-27 14:11:49

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

frieder · 2024-04-27 14:48:34

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)

frieder · 2024-04-27 16:36:24

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?

astralc · 2024-04-27 18:24:04

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).

frieder · 2024-04-27 20:32:55

> 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)

YCDA · 2024-05-16 23:00:41

So I've been exploring the vague depths of UEFI bootloaders and trying to learn the underlying processes as well, and I can share some of what I've learnt in regards to your questions.

* 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?

First, you are able to execute arbitrary efi files regardless if they are signed by your PK or MOK enrolled signature most likely because of the trusted inheritance given by your Trusted Database Keys (DB) , which appears to be the Microsoft Vendor CA/keys. From what I understand, those keys are quite generous and blanket various vendors and drivers given the reality that Windows is an operating system that must tailor it's development as a system for universal consumption and production. In addition, the arbitrary efi files you are able to execute could likely be in-scope (or "in-tree", not "out-of-tree") with your linux kernel, thus allowing such drivers, binaries, and kernels to be accepted by your default SHIM (usually the platform default signing key). For example, some kernels are not automatically loaded, but are still present in your linux kernel. The process you take in which you add a boot entry (if you are speaking of loading kernel modules or initializing module parameters) is considered secure by your system unless your kernel or Trusted Keys Database (DB) / Forbidden Signatures (DBX) says otherwise.

Why was rEFInd+PreLoader not able to use the ext4 driver untill I added the boot entry?

Second, regarding why rEFind+PreLoader were not able to use your ext4 driver until you added a boot entry. My guess here is that the ext4 driver was out of spec and required kernel signing, or that it just needed to be added to your early loading or module loading settings. From what I've understood from your text above, that's what I think.

Also I was thinking you could possibly explore your secure boot setup with some other tools I use, which are mokutil and good old openssl. Here's some commands you could try out:

You can export and retrieve all of your secure boot variables using the mokutil , and then use openssl to view some of the exported certificates/keys (which may adhere to your want for finding info on the public keys that are enrolled in your system).

This will just basically print your enrolled MOK keys (these are different than your secure boot PK which validates the UEFI process) and are strictly for kernel/dkms signing.

sudo mokutil --list-enrolled

These print out the certs and info for the other parts of the secure boot chain: PK --> KEK --> DB/DBX

sudo mokutil --pk
sudo mokutil --db
sudo mokutil --kek
sudo mokutil --dbx

Here we can actually export the keys enrolled as a .DER file, which is actually basically just an X509 openssl CA, which we can view

sudo mokutil --export

This will export the enrolled keys to your current directory, usually with a name like MOK-001.der / MOK-002.der, and we can then leverage openssl to view them.

sudo openssl x509 -in ./MOK-001.der -noout -text

Then if we want to delete them from MokManager, we can run this command which will ask for us to give a password to use when we reboot and are prompted by MokManager, to "view key" or "delete key"

sudo mokutil --delete ./MOK-001.der           # where you specify the key by using the .DER file we exported.

What has worked for me in the secure-boot process as of lately, is to delete all of my keys and secure-boot variables completely, and then from the motherboard bios set the mode to like user mode where everything is empty. Then I use the tool sbctl which you mentioned above to verify, create, enroll (with the --m flag to include Microsoft's DB's), and it just refresh's and creates a clean slate with your own PK that should be good to go even if you decide to later dual boot windows, since your self generate PK will have signed the Microsoft DB's which are usually the gatekeeper hinderance that can cause people problems.

Hopefully something here was helpful and I was on page with what you were looking for, let me know if you want any help with setting your stuff up or my thoughts about secure boot and security implications.

- YCDA

Last edited by YCDA (2024-05-16 23:13:27)

Arch Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#8 2024-05-16 23:00:41

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

Board footer