You are not logged in.

#1 2019-10-09 14:05:06

xand
Member
Registered: 2015-01-11
Posts: 16

[Solved] Secure boot understanding

Hello guys,
I've followed the 'Secure boot' page on the wiki (along with the recommended Rodsbooks article) in order to 'use my own keys' method.

I've signed the 'linux' kernel and 'grubx64.efi'. Everything went fine and I can confirm secureboot is enabled on my system with the suggested 'od' command returning the '60001' string.

However, I also have 'linux-lts' kernel installed and available as a boot option on grub. This one I did NOT sign, and if I choose to boot it, for my surprise, it does! So why isn't secure boot blocking it?

Last edited by xand (2019-10-14 22:32:25)

Offline

#2 2019-10-09 15:27:56

sabroad
Member
Registered: 2015-05-24
Posts: 242

Re: [Solved] Secure boot understanding

xand wrote:

'linux-lts' kernel installed and available as a boot option on grub. This one I did NOT sign, and if I choose to boot it, for my surprise, it does! So why isn't secure boot blocking it?

In a Secure Boot context, GRUB must be loaded by shim in order to verify kernel signatures.

Rodsbooks' Secure Boot (empasis mine):

Most recent versions of GRUB 2 communicate with Shim for authenticating Linux kernels and so will refuse to launch a Linux kernel that's not been signed, at least when GRUB is launched via Shim.

Implementation_of_UEFI_Secure_Boot-Shim:

Before booting a kernel, GRUB 2 calls back into shim to verify the AuthentiCode signature of the kernel.

Edit: as far as Secure Boot is concerned, by signing GRUB, you certify that it's trusted (to load kernel code). It's up to the signed artifact to continue verifying signatures (eg. kernel modules, etc).

Last edited by sabroad (2019-10-09 15:34:17)


--
saint_abroad

Offline

#3 2019-10-09 20:01:07

xand
Member
Registered: 2015-01-11
Posts: 16

Re: [Solved] Secure boot understanding

First of all, thanks for you quick and elucidating explanation!

IMO, the wiki is not clear about your statement, nor the fact that shim should be used even if your goal is not using microsoft keys at all.

Anyways, I'll try to include shim on my current setup as soon as possible and post results.

Offline

#4 2019-10-09 20:38:07

Swiggles
Member
Registered: 2014-08-02
Posts: 266

Re: [Solved] Secure boot understanding

Imo the only safe way (I am happy with) to use secure boot on a none encrypted device (e.g. boot) is to actually sign the whole chain and boot it directly through EFI

/etc/commandline.conf

root=... rw
objcopy \
    --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=0x20000 \
    --add-section .cmdline="/etc/commandline.conf" --change-section-vma .cmdline=0x30000 \
    --add-section .linux="/boot/vmlinuz-linux" --change-section-vma .linux=0x40000 \
    --add-section .initrd="/boot/initramfs-linux.img" --change-section-vma .initrd=0x3000000 \
    "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "/efi/EFI/Linux/Arch.efi"

One caveat: If you use Intel you have to combine the initramfs

cat /boot/intel-ucode.img /boot/initramfs-linux.img > /boot/initramfs-linux-microcode.img

and change it accordingly.

And sign your bundle after:

sbsign --key efi.key --cert efi.crt --output /efi/EFI/Linux/Arch.efi /efi/EFI/Linux/Arch.efi

Ofc you have to add it to your EFI: https://wiki.archlinux.org/index.php/EF … _.efi_file

efibootmgr --create --disk /dev/sda --part 1 --label "Arch Linux" --loader "\EFI\Linux\Arch.efi" --verbose

So the whole procedure is simply this after each kernel upgrade (hint make it a pacman hook):

#!/bin/bash
OUTPUT=/efi/EFI/Linux/Arch.efi
KEY=/root/efi.key
CERT=/root/efi.crt

CMDLINE=/etc/commandline.conf
VMLINUZ=/boot/vmlinuz-linux
INITRD=/boot/intel-ucode.img /boot/initramfs-linux.img

initrd_tmp=$(mktemp /tmp/initrd.XXXXXX)
cat $INITRD > $initrd_tmp

objcopy \
    --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=0x20000 \
    --add-section .cmdline="$CMDLINE" --change-section-vma .cmdline=0x30000 \
    --add-section .linux="$VMLINUZ" --change-section-vma .linux=0x40000 \
    --add-section .initrd="$initrd_tmp" --change-section-vma .initrd=0x3000000 \
    "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "$OUTPUT"
rm $initrd_tmp
sbsign --key "$KEY" --cert "$CERT" --output "$OUTPUT" "$OUTPUT"

So we skip grub, shim etc and directly boot what we actually want.
This is my adaption of many similar variations you can find online. Unfortunately I do not know the original source, but I think it is quite elegant. Although It is not documented in the wiki yet.

Ofc this allows/requires us to roll out our own keys, but I think that's reasonable. Imho the default (MS) keys are not trustworthy, because they were used to sign untrustworthy code and should therefore be removed.

Last edited by Swiggles (2019-10-09 20:45:19)

Offline

#5 2019-10-11 21:31:10

xand
Member
Registered: 2015-01-11
Posts: 16

Re: [Solved] Secure boot understanding

@Swiggles,
this is awesome, because of your post I was able to figure out the path to implement secureboot signing my keys, direct booting, but used sbupdate as a small variation of your method, so thank you lots.

I've also seen this building of the efi bundle with objcopy on sbupdate's code and this tutorial https://bentley.link/secureboot/, so maybe you got this from them or anywhere else because the wiki really miss that.

I have not gone thru trying to implement this tutorial link I wrote above, but he uses systemd-boot without shim, so I still wonder why he have not gone thru the same issue I reported here since he's signing both the bootmanager and the kernel.

Offline

#6 2019-10-11 23:44:40

Swiggles
Member
Registered: 2014-08-02
Posts: 266

Re: [Solved] Secure boot understanding

Good question. I think it's another adaption of the same process though, because it differs in one very important detail.
Assuming systemd-boot verifies the whole chain I don't think there is anything wrong with it. I don't know though and it has to be tested.
EFI itself already behaves like a boot manager for many systems so it is not always required even for multi boot.

Overall I think the proposed solution in your link is great for the general case, but I don't think it is necessary for many setups and can be simplified by just booting directly.

Also this is the crux of the whole process, you have to be sure every step is verified or the whole chain fails from a security standpoint (unfortunately silent failure as described in your first post). I mentioned in my previous post that I am happy with the approach, because it has an inherent guarantee that anything required during boot is actually verified by combining everything in a singular efi binary. Or in other words I don't know either, but it does not matter as long as you know the whole chain (1 file) is verified.

Anyway, I am glad it was helping you with your setup. smile

Offline

Board footer

Powered by FluxBB