Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GRUB cannot boot with secure boot
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
FlyingBullets
n00b
n00b


Joined: 19 Mar 2024
Posts: 11

PostPosted: Sat Dec 14, 2024 5:11 pm    Post subject: GRUB cannot boot with secure boot Reply with quote

#######
PROBLEM
#######

I'm trying to use secure boot with my setup, but I keep getting errors in GRUB.

#####
SETUP
#####

My setup is the following:
Drive Partition_name Mountpoint
/dev/sda
|-/dev/sda1 EFI System /efi
|-/dev/sda2 Linux extended boot /boot
`-/dev/sda3 Linx filesystem

sda1 is the ESP where the '.efi' file is /efi/EFI/BOOT/BOOTX64.EFI

sda2 is the XBOOT that contains:
|-grub/
|-amd-uc.img
|-intel-uc.img
|-System.map-x.y.z-gentoo
|-config-x.y.z-gentoo
|-initramfs-x.y.z-gentoo.img
`-vmlinuz-x.y.z-gentoo

sda3 is the encrypted root.

sys-kernel/installkernel is compiled with:
USE="dracut grub"

sys-boot/grub is compiled with:
USE="device-mapper fonts nls secureboot themes"
GRUB_PLATFORMS="efi-64"

GRUB is installed with the following command:
Code:
grub-install --removable --target=x86_64-efi --efi-directory=/efi


I compile my own kernel from sys-kernel/gentoo-sources.

The current setup works -- I use the installkernel script to configure Dracut and GRUB when I run 'make install'.

###################################
TRYING TO USE SECURE BOOT ATTEMPT 1
###################################

I followed the instructions on the "Secure Boot" wiki page up to section "Signing Boot Files":
- set SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT in make.conf
- make my own keys
- sign my keys
- install my keys to the UEFI

The "Signing Boot Files" section does not explain well what files need to be signed, it only shows the kernel being
signed and only talks about UKI and initramfs. I signed what I could and signed:
- /efi/EFI/BOOT/BOOTX64.EFI
- /boot/vmlinuz-x.y.z-gentoo
with
Code:
sbsign --cert my_db.crt --key my_db.key <efi file> --output <efi file>


I also checked they were signed with the right key with 'sbverify'.

When I try to boot, the GRUB menu doesn't show up and I'm given:
Code:
error: prohibited by secure boot policy.
Entering rescue mode...
grub rescue>


###################################
TRYING TO USE SECURE BOOT ATTEMPT 2
###################################

When I install sys-boot/grub with USE="secureboot", there is a message stating that it makes the signed standalone
GRUB executables in /usr/lib/grub/grub-<target>.efi(.signed) and that these executables need the grub.cfg file
in the same directory.

So I ran the following commands:
Code:
export GRUB_CFG=/efi/EFI/BOOT/grub.cfg
cd /usr/src/linux
make install
cp /usr/lib/grub/grub-x86_64.efi.signed /efi/EFI/BOOT/BOOTX64.EFI
sbsign --cert my_db.crt --key my_db.key /boot/vmlinuz-x.y.z-gentoo --output /boot/vmlinuz-x.y.z-gentoo


I verified the efi and kernel were both signed and rebooted. The GRUB menu showed up like normal and gave me the
usual options:
Code:
Gentoo GNU/Linux
Advanced options for Gentoo GNU/Linux
UEFI Firmware Settings


But when I tried to boot Gentoo, I get the following error:
Code:
Loading Linux x.y.z-gentoo ...
error: shim_lock protocol not found.
Loading initial ramdisk ...
error: you need to load the kernel first.

Press any key to continue...


I did some more research, but everyone seems to have their own solution that only applies to them:
- some say use UKI
- some say build the initramfs into the kernel
- something something GRUB modules
- grub-install options

I tried various solutions, but nothing seems to work.
Back to top
View user's profile Send private message
rab0171610
Guru
Guru


Joined: 24 Dec 2022
Posts: 441

PostPosted: Sat Dec 14, 2024 5:41 pm    Post subject: Reply with quote

My solution is to disable it entirely. I assume you have decided that you are at high risk of unauthorized code execution, a bootkit, or some sort of malware that specifically affects your Linux installation. My question, seeing your exhaustive efforts to enable and troubleshoot secure boot, is are you sure you really need it?
Do you have reason to believe that your system integrity is at risk and need to verify it every time you boot?
If you do not need it after all, then simply disable it. If you feel you %100 require it or benefit from it for your use case, then proceed.
Obviously, if you must dual-boot with Windows for some reason, it may be difficult to avoid. Otherwise it is optional.
Back to top
View user's profile Send private message
FlyingBullets
n00b
n00b


Joined: 19 Mar 2024
Posts: 11

PostPosted: Sat Dec 14, 2024 6:24 pm    Post subject: Reply with quote

Quote:
My question, seeing your exhaustive efforts to enable and troubleshoot secure boot, is are you sure you really need it?


Yes.
Back to top
View user's profile Send private message
Child_of_Sun_24
l33t
l33t


Joined: 28 Jul 2004
Posts: 603

PostPosted: Sat Dec 14, 2024 6:31 pm    Post subject: Reply with quote

I use secureboot with sys-boot/shim and it works with dual-boot windows.

https://wiki.gentoo.org/wiki/Shim

Here is everything discribed what you need for it.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 5219
Location: Bavaria

PostPosted: Sat Dec 14, 2024 7:03 pm    Post subject: Re: GRUB cannot boot with secure boot Reply with quote

FlyingBullets,

SecureBoot means: Your UEFI verify the signature of the FIRST application it starts. This can be a bootloader/-manager OR a Linux kernel (or Windows). If it is grub - and UEFI has started your grub, ANYTHING else is THEN the job of grub. This means: If you dont want that somebody exchange your kernel then you must configure GRUB so that it verify ALSO your kernel. There was a description for this in our forum (at first glance it was very complicated) and I had forgotten it ... because the simplest way (for me) WHEN using SecureBoot is: Start your signed kernel directly via UEFI ... ;-)

In this article is also a link to my (manually) SecureBoot solution:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Boot_kernel_via_UEFI

Another story is ... a UKI ... If you need SecureBoot you should not use a kernel WITH an external initramfs. If you need an initramfs (because your root partition is encrypted) then USE an embedded initramfs. You have two choices to do this:

1. Automatically with installkernel, or
2. Manually: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Initramfs_Overview#Special_Case:_Building_an_embedded_initramfs_with_a_CPIO_archive

FlyingBullets wrote:
[...] I compile my own kernel from sys-kernel/gentoo-sources.

Maybe you are interested in this:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_kernel_configuration
https://wiki.gentoo.org/wiki/User:Pietinger/Experimental/Manual_Configuring_Current_Kernel
_________________
https://wiki.gentoo.org/wiki/User:Pietinger
Back to top
View user's profile Send private message
rab0171610
Guru
Guru


Joined: 24 Dec 2022
Posts: 441

PostPosted: Sat Dec 14, 2024 7:33 pm    Post subject: Reply with quote

FlyingBullets wrote:
Quote:
My question, seeing your exhaustive efforts to enable and troubleshoot secure boot, is are you sure you really need it?


Yes.

Perfectly understandable. I wanted to put it out there because it is a valid question that users should be asking themselves before spending the time and effort in setting it up and troubleshooting -- as might be the case for other users who read this post in the future.
Back to top
View user's profile Send private message
FlyingBullets
n00b
n00b


Joined: 19 Mar 2024
Posts: 11

PostPosted: Sat Dec 14, 2024 8:01 pm    Post subject: Reply with quote

Quote:
I use secureboot with sys-boot/shim...

I don't want to use shim; I want to use my own keys.

Quote:
If you need an initramfs (because your root partition is encrypted) then USE an embedded initramfs.

I'm going to try several things:
- Dracut has some uefi parameters to embed the initramfs Update: I don't think this does what I think it does.
- Using an EFI Stub to be loaded by GRUB
- UKI

Quote:
If it is grub - and UEFI has started your grub, ANYTHING else is THEN the job of grub.


That's how I want things to be handled; I want to keep using GRUB so that I can switch between kernels in case I mess something up; I don't want to boot directly into a kernel. I get that all executables should be signed, but that didn't work.

What I would like to know is why GRUB is giving me this "shim_lock" error.

Update:
The "EFI Stub" wiki page is not helpful in learning how to actually embed an initramfs, it only talks about the subject and something about CPIO files. It says that Dracut can make them, but I can't find anything in the Dracut man pages about ".cpio" files. Also, I'm being told to set CONFIG_INITRAMFS_SOURCE=/usr/src/initramfs ...but that doesn't exist?
Back to top
View user's profile Send private message
FlyingBullets
n00b
n00b


Joined: 19 Mar 2024
Posts: 11

PostPosted: Sat Dec 14, 2024 9:10 pm    Post subject: Reply with quote

As a sanity check, I made a UKI by following the instructions on the "Unified kernel image" wiki page; I was able to boot with secure boot, but I had to boot directly into the kernel.

I'm still working on getting GRUB to work.
Back to top
View user's profile Send private message
zen_desu
n00b
n00b


Joined: 25 Oct 2024
Posts: 53

PostPosted: Sat Dec 14, 2024 9:12 pm    Post subject: Reply with quote

If you want to embed a CPIO archive into the kernel, you must remove compression on that file if there is any.

If you want to embed a dracut initramfs into the kernel, I think you have to use special tools to extract it because Dracut makes a "layered" CPIO for early microcode.

Once extracted, you can point CONFIG_INITRAMFS_SOURCE to the directory containing the extracted initramfs.

You do not need to embed the initramfs for secure boot. This just ensures the initramfs is signed because the whole kernel (containing the initramfs) is signed.

A more straightforward method is to use a UKI.

FlyingBullets wrote:
As a sanity check, I made a UKI by following the instructions on the "Unified kernel image" wiki page; I was able to boot with secure boot, but I had to boot directly into the kernel.

I'm still working on getting GRUB to work.


I would just do this tbh. Getting GRUB to work with SB is a bit of a pain. If you can directly boot into the kernel, why not do that?
_________________
µgRD dev
Wiki writer
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 5219
Location: Bavaria

PostPosted: Sat Dec 14, 2024 9:25 pm    Post subject: Reply with quote

zen_desu wrote:
If you want to embed a CPIO archive into the kernel, you must remove compression on that file if there is any. [...]

Are you sure? I ask because /usr/src/linux/usr/Makefile says:
Code:
# If CONFIG_INITRAMFS_SOURCE specifies a single file, and it is suffixed with
# .cpio, use it directly as an initramfs.
ifneq ($(filter %.cpio,$(ramfs-input)),)
cpio-data := $(ramfs-input)
endif

# If CONFIG_INITRAMFS_SOURCE specifies a single file, and it is suffixed with
# .cpio.*, use it directly as an initramfs, and avoid double compression.
ifeq ($(words $(subst .cpio.,$(space),$(ramfs-input))),2)
cpio-data := $(ramfs-input)
compress-y := copy
endif

... see the 2nd part -> # .cpio.*

and in my article I wrote:
Quote:
It is important to use suffix .cpio so "make" understand it is a CPIO file !

It is important to use suffix .cpio.gz so "make" understand it is an already gzipped CPIO file

_________________
https://wiki.gentoo.org/wiki/User:Pietinger
Back to top
View user's profile Send private message
zen_desu
n00b
n00b


Joined: 25 Oct 2024
Posts: 53

PostPosted: Sat Dec 14, 2024 9:37 pm    Post subject: Reply with quote

pietinger wrote:
zen_desu wrote:
If you want to embed a CPIO archive into the kernel, you must remove compression on that file if there is any. [...]

Are you sure? I ask because /usr/src/linux/usr/Makefile says:
Code:
# If CONFIG_INITRAMFS_SOURCE specifies a single file, and it is suffixed with
# .cpio, use it directly as an initramfs.
ifneq ($(filter %.cpio,$(ramfs-input)),)
cpio-data := $(ramfs-input)
endif

# If CONFIG_INITRAMFS_SOURCE specifies a single file, and it is suffixed with
# .cpio.*, use it directly as an initramfs, and avoid double compression.
ifeq ($(words $(subst .cpio.,$(space),$(ramfs-input))),2)
cpio-data := $(ramfs-input)
compress-y := copy
endif

... see the 2nd part -> # .cpio.*

and in my article I wrote:
Quote:
It is important to use suffix .cpio so "make" understand it is a CPIO file !

It is important to use suffix .cpio.gz so "make" understand it is an already gzipped CPIO file


Ah that explains why I had issues in the past. Initramfs images are often installed with a .img suffix. I don't recall if this worked when it was a plain CPIO, but I definitely had issues when the compression extension was not included, as it often is not.
_________________
µgRD dev
Wiki writer
Back to top
View user's profile Send private message
FlyingBullets
n00b
n00b


Joined: 19 Mar 2024
Posts: 11

PostPosted: Sat Dec 14, 2024 10:01 pm    Post subject: Reply with quote

Quote:
If you can directly boot into the kernel, why not do that?

I would like to have a menu of different kernels to select from when I boot the machine. If a new kernel build doesn't boot, I can easily select another one. Although, using a UKI means that only one file has to be unencrypted outside of full disk encryption, I can keep everything in /boot on the same partition as root. But that shouldn't matter as long as the GRUB efi and kernel (with embedded initramfs) are signed right? There shouldn't be any holes in the boot chain right?

Quote:
I think you have to use special tools to extract it because Dracut makes a "layered" CPIO for early microcode.

Dracut makes files with extension ".img", is there a way to convert them to ".cpio"? I tried setting CONFIG_INITRAMFS_SOURCE=/usr/lib/dracut and it didn't error, but I was still unable to achieve my goal.
Back to top
View user's profile Send private message
zen_desu
n00b
n00b


Joined: 25 Oct 2024
Posts: 53

PostPosted: Sat Dec 14, 2024 10:08 pm    Post subject: Reply with quote

If your system has a boot menu, you can use that. I do that on most of my systems, I can press f12 or whatever to see boot options and change which kernel version I'm booting into.
You can also install an EDK2 shell to your ESP if your UEFI doesn't have similar. Using that, you can boot any kernel/initramfs/cmdline you want.

Technically a UKI means you only need a single unencrypted file, but it has components equivalent to multiple files, more or less. You can almost treat it like a self extracting archive. When it runs, it extracts parts such as the kernel/initramfs from itself.

It being a single file mostly helps with signing as only a single file must be signed.

I think you can simply change the extension of the dracut ".img" to ".cpio.zstd" for example, if it uses zstd compression.

CONFIG_INITRAMFS_SOURCE should target either the initramfs file (properly suffixed) or a directory containing the initramfs tree which will be packed as part of the kernel build process.
_________________
µgRD dev
Wiki writer
Back to top
View user's profile Send private message
sMueggli
Guru
Guru


Joined: 03 Sep 2022
Posts: 511

PostPosted: Sun Dec 15, 2024 1:50 pm    Post subject: Reply with quote

I think you did not sign all the necessary parts of Grub. For example the "insmod" commands in grub.cfg will fail. The needed modules have to be part of the standalone Grub image.


Links:


And why are you using "--removable"? As long as you have no other systems, you will not see any difference. But the "\EFI\BOOT\BOOTx64.efi" might be overwritten with other EFI binaries.
Back to top
View user's profile Send private message
Nowa
Developer
Developer


Joined: 25 Jun 2014
Posts: 447
Location: Nijmegen

PostPosted: Sun Dec 15, 2024 8:08 pm    Post subject: Re: GRUB cannot boot with secure boot Reply with quote

FlyingBullets wrote:

GRUB is installed with the following command:
Code:
grub-install --removable --target=x86_64-efi --efi-directory=/efi



This cannot work, grub-install will by default create a modular grub without an sbat section. The sbat section is required to boot with shim. And loading modules is prohibited when secure boot is enabled (hence your 'error: prohibited by secure boot policy.').

Instead, enable the "secureboot" flag on sys-boot/grub and follow the steps in the handbook: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader#Optional:_Secure_Boot (copy the prebuilt stand-alone /usr/lib/grub/grub-x86_64.efi.signed, register with efibootmgr, generate grub.cfg and set GRUB_CFG in the environment)

UKI is separate to the issue at hand, note that grub does NOT support loading UKI's with secureboot enabled through shim (this requires patches from Ubuntu or Fedora, see https://bugs.gentoo.org/942201)
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1764
Location: South America

PostPosted: Mon Dec 16, 2024 12:13 am    Post subject: Re: GRUB cannot boot with secure boot Reply with quote

FlyingBullets wrote:
I did some more research, but everyone seems to have their own solution that only applies to them:
- some say use UKI
- some say build the initramfs into the kernel
- something something GRUB modules
- grub-install options

That's because setting up secure boot is actually quite complex, and so, a) many people don't bother, which reduces the pool of experienced people, b) a lot of documentation is written in tutorial or instruction list format (and this includes the Handbook's section on it), which obviously applies to the one setup the author wished to document (in the case of the Handbook, that's the Shim), and excludes other possibilities. One of which might just be the one you would like to set up :) So here's one long attempt at clarification.

Disclaimer: I use (and even like) GRUB2 even with UEFI setups, I don't use secure boot, and if I did, I would go with the Shim and a MOK. That said, I spent some time reading GRUB's code to find out stuff that does not appear in documentation, which also means I could have gotten it wrong.

First:

FlyingBullets wrote:
The "Signing Boot Files" section does not explain well what files need to be signed, it only shows the kernel being
signed and only talks about UKI and initramfs. I signed what I could and signed:
- /efi/EFI/BOOT/BOOTX64.EFI
- /boot/vmlinuz-x.y.z-gentoo
with
Code:
sbsign --cert my_db.crt --key my_db.key <efi file> --output <efi file>

One has to understand that there are three mechanisms for verifying files with digital signatures, that could be used in secure boot scenarios. All of them make use of asymmetric encryption, and therefore, a public and a private signing key pair, so they all generically involve "signing" of some sort, but their technical details are actually different:
  1. The mechanism used by UEFI firmware and the Shim. I will call it the "secure boot mechanism", because is it the one actually described in the UEFI specification, and will do that even though the Shim is a sort of add-on.
  2. A mechanism that can be used by GRUB for verifying files that it reads once it is running, independent of the secure boot mechanism. More on this later in the post.
  3. The mechanism used by the kernel for verifying the kernel modules that it loads. I won't talk about it here.
Now, sbsign is only used for signing files that will be verified with the mechanism #1. And these can only be of one type: EFI PE32+ files. So, which files are PE32+ files that could appear in a secure boot scenario? They are:
  • EFI stub kernels. They resemble PE32+ files.
  • The bootloader's EFI executable, if you are using one. That's grubx64.efi for GRUB.
  • The Shim, shimx64.efi, if you are using it.
  • Unified Kernel Images (UKI), if you are using them.
Here's the first set of alternatives that complicates any attempt at making a general secure boot article. So, which scenario is the one you want? That's the second one, i. e. the bootloader scenario.

Second: you want GRUB, so clearly, sbsign would be used at least for signing its EFI executable. But now you also have to satisfy GRUB's additional requirements. And you see, when GRUB detects that it is being run with secure boot enabled, it enters a mode of operation called "lockdown mode". Lockdown mode prevents you from doing stuff that could compromise the security. And one of its requirements is that, when GRUB is asked to read a file, if it is of certain types, then it must be verified with a digital signature. And these types of files include Linux kernels and GRUB modules.

Therefore, as Nowa said, attempt 1 failed with:

FlyingBullets wrote:
Code:
error: prohibited by secure boot policy.
Entering rescue mode...
grub rescue>

Third: How do you make GRUB accept a kernel in lockdown mode? There's two ways, apparently:
  1. GPG-style detached signatures, which is mechanism #2 in the previous list, and is documented in GRUB's manual. This can be used to sign arbitrary files, not just EFI PE32+ ones, but is competely independent of the secure boot mechanism, which I'm sure has the potential to confuse people.
  2. The secure boot mechanism. Which would only work with PE32+ files, so kernels have to be EFI stubs that you must also sign with sbsign.
While alternative #2 is mentioned in the manual, you'll note that the corresponding section is quite slim.

Now, what I think is the real problem in your case: I believe, from looking at the code, that alternative #2 can only be used when the Shim is installed, even if you have replaced all keys in the UEFI secure boot db. It's because the Shim installs some sort of callback mechanism that bootloaders can then use to verify signatures on PE32+ files, with keys in the UEFI secure boot db and MOKs (which are not needed in your case), and GRUB seems to rely on that. That's the "shim lock protocol" in this message:

FlyingBullets wrote:
Code:
Loading Linux x.y.z-gentoo ...
error: shim_lock protocol not found.
Loading initial ramdisk ...
error: you need to load the kernel first.

Press any key to continue...

I believe that attempt 2 failed because you don't have the Shim.

Fourth: GRUB will make you use the GPG-style detached signatures alternative if it is asked to read a file that requires verification in lockdown mode, but is not an EFI PE32+ file. Most important files of this type are GRUB modules. So if you want to avoid that, the solution is to embed all needed modules in GRUB's core image. The automation in Gentoo's ebuild activated by setting the secureboot USE flag does that to an extent, but I'm not sure it guarantees that there will never be a need to load a module. Or read a file other than a PE32+ one that needs verification.

So what then? It looks like, if you want to use GRUB, you'd have to either use the GPG-style detached signatures alternative, which Gentoo's automation will not set up for you, or try installing the Shim, and signing it with one of your keys. Gentoo's Shim is already signed with a signature that you probably won't be able to verify with the keys in your UEFI db, if you replaced its contents. I don't know if you can just use sbsign with a signed file, or if it is more complicated than that.

There's an old thread here somewhere from someone that managed to make GRUB boot with secure boot enabled and GPG-style detached signatures.

EDIT to add Just to be clear:

FlyingBullets wrote:
I followed the instructions on the "Secure Boot" wiki page up to section "Signing Boot Files":
- ...
- make my own keys
- sign my keys
- install my keys to the UEFI
FlyingBullets wrote:
Quote:
I use secureboot with sys-boot/shim...

I don't want to use shim; I want to use my own keys.

I assumed in all places where I referred to your specific setup that this means "I replaced the Platform Key, Key Exchange Keys and all keys in the secure boot db with my own".
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Ionen wrote:
As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though :)
Back to top
View user's profile Send private message
FlyingBullets
n00b
n00b


Joined: 19 Mar 2024
Posts: 11

PostPosted: Mon Dec 16, 2024 4:11 am    Post subject: Reply with quote

sMueggli wrote:
I think you did not sign all the necessary parts of Grub. For example the "insmod" commands in grub.cfg will fail. The needed modules have to be part of the standalone Grub image.

You are correct, after reading the info pages of GRUB, I learned that GRUB must have the modules it uses embedded at install time (grub-install) or the modules need to be signed with a GPG key that GRUB checks; the key is given to GRUB at install time with "-k, --pubkey". When I used Gentoo's automatically generated GRUB efi file (/usr/lib/grub/grub-x86_64.efi.signed) it had a size of 14M; the original one (before I went on this secure boot journey) was 294K; this leads me to believe that Gentoo's automatically generated one embeds the modules and why I was able to boot Gentoo's, but not mine. I remember seeing a "insmod" error one time attempting to boot, but I can't remember what configuration I had because I've already gone through 30.

When I tried to do this manually:
Code:
grub-install --removable --target=x86_64-efi --efi-directory=/efi --modules="$(ls /boot/grub/x86_64-efi | grep -E '\.mod$')"

I got an efi file of size 2.8M; it booted, but I was not met with the normal menu, I was met with the following screen:
Code:
                            GNU GRUB version 2.12
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions. To enable less(1)-like paging, "set
pager=1".

grub>


sMueggli wrote:
And why are you using "--removable"? As long as you have no other systems, you will not see any difference. But the "\EFI\BOOT\BOOTx64.efi" might be overwritten with other EFI binaries.

I installed Gentoo on one machine so many times that I filled up the NVRAM and kept getting errors from "grub-install". I spent a day debugging it and added a solution to GRUB/Troubleshooting (the solution was on the Arch wiki: delete "dump-*" files in NVRAM). I use "--removable" because it doesn't modify the UEFI, it uses the generic "/EFI/BOOT/BOOTX64.EFI".

GDH-gentoo wrote:
I assumed in all places where I referred to your specific setup that this means "I replaced the Platform Key, Key Exchange Keys and all keys in the secure boot db with my own".

Correct.


GDH-gentoo wrote:
1. The mechanism used by UEFI firmware and the Shim. I will call it the "secure boot mechanism", because is it the one actually described in the UEFI specification, and will do that even though the Shim is a sort of add-on.
2. A mechanism that can be used by GRUB for verifying files that it reads once it is running, independent of the secure boot mechanism. More on this later in the post.
3. The mechanism used by the kernel for verifying the kernel modules that it loads. I won't talk about it here.

I think you explained it best. I thought secure boot was, "the UEFI checks all executable files when booting". But there is actually a boot chain where each step checks the next with it's own method:
1. The UEFI checks the signature of the efi file to boot (GRUB in my case) with it's own keys.
2. GRUB checks the signature of it's modules and kernel to boot with it's own keys.
3. The kernel checks the signature of it's modules to probe with it's own keys.
So really, I have 3 sets of keys: one for the UEFI and efi file, one for GRUB and it's modules and the kernel (and initramfs?), and one for the kernel and it's modules.
I guess I have steps (1) and (3) done because I already use signed kernel modules.


GDH-gentoo wrote:
So what then? It looks like, if you want to use GRUB, you'd have to either use the GPG-style detached signatures alternative, which Gentoo's automation will not set up for you, or try installing the Shim, and signing it with one of your keys. Gentoo's Shim is already signed with a signature that you probably won't be able to verify with the keys in your UEFI db, if you replaced its contents.

I'm okay with using PGP keys -- learning something new is fun :3 I can make a script to automate the signing, I just need to know what exactly to sign >.<
There is a section in the GRUB info pages that if shim is not going to be used, then the "--disable-shim-lock" option must be added to the "grub-install" command.
EDIT: I also read in the info pages that "--efi-directory" AND "--boot-directory" must be used when using "--removable", but I never ran into problems... until now...

GDH-gentoo wrote:
I don't know if you can just use sbsign with a signed file, or if it is more complicated than that.

I can concatenate the factory keys and my keys so that they both work, this is explained in the "Secure Boot" wiki page:
Code:
cat factory/db.esl custom/db.esl >new_db.esl







Heh, as I'm typing this post, I'm trying to get back to my default setup and I keep discovering new errors >.<
My latest one is:
Code:
Booting `Gentoo GNU/Linux'
Loading Linux x.y.z-gentoo.efi...
Loading initial ramdisk...
systemd-boot: Assertion 'device' failed at ../systemd-stable-254.17/src/boot/efi/part-discovery.c:251@partition_open, halting.

EDIT: Woops! GRUB was trying to load an efi file with the same name as the kernel and it showed up first in the menu without me noticing: vmlinuz-x.y.z-gentoo(.efi)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum