[SOLVED] Secure Boot: I don't understand the benefit of shimx64

musbur · 2024-01-15 09:39:13

Background ('ll get to shimx64 in a minute): I just want to protect my private data from casually prying eyes should my laptop get lost or stolen. Not more. Therefore I have a LUKS-encrypted root file system.

Do I need Secure Boot for that? No. Why do I want SB? To more easily dual boot Windows and Arch (either by switching the bootloader with some function key on startup in the BIOS or via another loader like GRUB).

OK. So I want SB. Problem? I can't get it to work. Why? Because I don't understand it. Why do I need to understand it when I might as well just follow the usually excellent Arch instructions to a T? Because I don't roll that way, and if I did, I wouldn't be using Arch. I switched from Slack to Debian in 1999 and to Arch in 2021 because I missed the challenge. Debian was secure-booted via shimx64 and grub, and so was the Arch system I bootstrapped from that. Automatic re-signing of stuff on updates and all. I forgot how I got it to work, and I recently broke that Arch system and haven't been able to set it up again.

Here's what I do understand. Please correct me if I'm wrong: SB only boots .efi binaries that are signed with a key whose certificate is stored in the firmware's NVRAM. That can either be a preconfigured key by Microsoft or a MOK that I make myself and enroll into the NVRAM.

The most straightforward way to implement this is using a Unified Kernel Image (UKI) signed with the MOK. One single .efi binary that does the whole boot process. Easy to understand but non-trivial (to me) to implement. Haven't tried it yet.

Then there's shimx64.efi which worked for me before. This is signed by Microsoft and therefore doesn't need to be signed with a MOK. It does one thing and one thing only which is to load a bootloader called grubx64.efi (which doesn't actually have to be grub, it just needs to have that file name). But it only does that if grubx64.efi itself is signed with my MOK which has to be enrolled in NVRAM? So what's the advantage of shimx64 if the actual boot loader has to be signed anyway with my MOK?

Also the grubx64.efi binary has to have an "sbat" section which is just some CSV file with three URLs in it (one of them misspelled with no colon after https). I'm trying to use systemd-boot but have no idea where to get the sbat file from or what to put in it. That's where I'm currently stuck at. Does it matter if I use grub or another boot loader? I switched from grub to systemd-boot because grub seems overly bloated and convoluted to configure.

But even if I got systemd-boot to work with some invented or copied-from-grub sbat.csv file (haven't tried that yet): I don't understand how it would make a system more safe. The Secure Boot section in the Arch wiki explains how to MOK-sign the kernel and the boot loader, but not the initramfs. What would prevent an attacker to smuggle malicious code (such as spying the LUKS passphrase) into the unprotected initramfs? This is such an obvious hole that I can't imagine that the Linux SB developers haven't fixed it. So how does the kernel know if the initramfs has been tampered with?

Thanks!

Last edited by musbur (2024-01-17 18:52:18)

frostschutz · 2024-01-15 10:46:15

Windows still works fine without secure boot for now, so if that is the only reason, you don't really need it yet. I don't use it myself...

Otherwise if you really want it and also extend it to cover the initramfs, you can roll it all into one file, e.g. https://wiki.archlinux.org/title/Unified_kernel_image

shim is a helper to load things that wouldn't work directly. It has its own verification routines. Maybe the shim readme explains it a little better...

musbur · 2024-01-15 12:06:44

frostschutz wrote:

Windows still works fine without secure boot for now, so if that is the only reason, you don't really need it yet. I don't use it myself...

Not under my control on this machine. Windows is secure boot + Bitlocker.

frostschutz wrote:

Otherwise if you really want it and also extend it to cover the initramfs, you can roll it all into one file, e.g. https://wiki.archlinux.org/title/Unified_kernel_image

Yeah. I said that. Looking into it.

frostschutz wrote:

shim is a helper to load things that wouldn't work directly. It has its own verification routines. Maybe the shim readme explains it a little better...

Not good enough for me it seems, which is why I explicitly asked about the things I didn't understand or find in the documentation.

-thc · 2024-01-15 15:35:11

Since every valid bootloader must be signed with a valid key and this approach maybe too cumbersome, secure boot implements the SHIM methods - one works like this:

The shim efi executable itself is signed and does a lookup inside the "MokList" for a valid checksum of the targeted loader. If the checksum is valid (an EFI utility called "MokManager" - mmx64.efi - can be used to add the checksum to the MokList) the loader (grubx64.efi) is started without having been signed at all.

jl2 · 2024-01-15 20:16:29

Not under my control on this machine. Windows is secure boot + Bitlocker.

Btw a (non windows/grub/systemd-boot) bootloader and bitlocker don't play well. bitlocker has some extra key stuff that looks that there's nothing in between firmware and windows. (asuming you're not using password unlocking)
systemd-boot has "reboot for bitlocker" that will set the bootnext variable and reboot to get around this.

musbur · 2024-01-16 08:19:30

-thc wrote:

Since every valid bootloader must be signed with a valid key and this approach maybe too cumbersome, secure boot implements the SHIM methods - one works like this:
The shim efi executable itself is signed and does a lookup inside the "MokList" for a valid checksum of the targeted loader. If the checksum is valid (an EFI utility called "MokManager" - mmx64.efi - can be used to add the checksum to the MokList) the loader (grubx64.efi) is started without having been signed at all.

That is interesting. So the shim loader doesn't provide any security at all but makes secure boot possible, which in turn makes only sense if you dual-boot an OS with mandatory secure boot.

This should be mentioned in the documentation. Yes, every page about Secure Boot mentions that other methods are "better" or "more secure," but not that shimx64 is just not secure at all.

I am aware of the fact that every security measure is just another obstacle to make attacking the machine more time consuming or inconvenient. But if what you say is true, shimx64 isn't much of a hurdle.

-thc · 2024-01-16 10:05:39

I take a more pragmatic point of view of boot security. My personal take is that Secure Boot was invented in the first place to protect against (Windows) Bootkits/Rootkits (without having physical access) which were fashionable for quite a while in the past. The idea of a complete chain of trust in every step of the boot process is nice but realistically unattainable for me.

As soon as the control is handed over from Secure Boot to the (signed) Windows Bootloader (bootmgfw.efi) it's job is done. Some time ago a malware team managed to exploit this in a clever way: a flawed version of "bootmgfw.efi" allowed the execution of Windows bootkits. Microsoft patched it on short notice (replacing "bootmgfw.efi" with a fixed version) but didn't blacklist the old version. The malware rolled back to the old "bootmgfw.efi", requested a reboot and installed it's bootkit anyway.

IMHO the SHIM methods were added to Secure Boot for the enabling of all those pesky unsigned Linux loaders and not as a benefit or for security. Nevertheless adding checksums to the MokList should require physical access - it's not completely insecure.

Don't forget that it may be possible to boot from a UEFI boot pendrive with a signed loader (Windows install medium or a modified WinPE boot medium) and alter the contents of the EFI partition at will - again requiring physical access.

musbur · 2024-01-17 08:45:11

-thc wrote:

IMHO the SHIM methods were added to Secure Boot for the enabling of all those pesky unsigned Linux loaders and not as a benefit or for security. Nevertheless adding checksums to the MokList should require physical access - it's not completely insecure.

That's a very sane and concise summary of what my feeling has been all along. If I wanted maximum security I'd make the whole internal SSD a single big LUKS-encrypted volume group, with EFI, LUKS header, and boot partition on a USB thumb drive. This would make the machine bootable only with the USB drive and wouldn't even require secure boot. If I'd ever lost control over the thumb drive I'd discard it and use a fresh copy (of which I'd have several in a safe place). Factory BIOS firmware, no custom boot entries or keys -- without the correct USB stick, sadly an unbootable laptop with an unpartitioned SSD full of random garbage and no hint as to if or how it has been used before.

If the hardware were mine and didn't need Windows. Alas it ain't.

Currently trying to get shimx64 to work with a signed UKI. Of course it doesn't work yet. Maybe I do have to use GRUB. Will report back.

Last edited by musbur (2024-01-17 08:46:36)

Head_on_a_Stick · 2024-01-17 18:27:30

You don't need the shim with a signed UKI. Just enroll your keys into the firmware and sign the image with them. Job done.

But switching to Windows will require the firmware boot menu, which defeats the purpose of this thread.

You could use systemd-boot and sign that as well, that should offer a multi-boot menu: https://wiki.archlinux.org/title/System … ecure_Boot ← no shim required for that either.

musbur · 2024-01-17 19:04:21

Head_on_a_Stick wrote:

You don't need the shim with a signed UKI. Just enroll your keys into the firmware and sign the image with them. Job done.

I know but judging by the Wiki it seems to be a pretty deep interference with the firmware with a certain potential of destruction if not done right. Also it seems to require re-signing all of the Microsoft stuff which I don't want to touch (because it isn't mine).

So now after I've wrapped my head around the concept, shim and MOK are pretty easy to use and not very firmware-intrusive (and yes, not particularly secure, especially with a separate unsigned initramfs). I've set up my pacman and initramfs hooks and everything works breezingly.

Until in couple of years when something breaks and I have forgotten everything. I'll be back!

Head_on_a_Stick · 2024-01-17 19:59:12

musbur wrote:

it seems to require re-signing all of the Microsoft stuff

Not if you keep the Microsoft keys, which is the recommended approach.

Arch Linux

#1 2024-01-15 09:39:13

[SOLVED] Secure Boot: I don't understand the benefit of shimx64

#2 2024-01-15 10:46:15

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#3 2024-01-15 12:06:44

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#4 2024-01-15 15:35:11

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#5 2024-01-15 20:16:29

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#6 2024-01-16 08:19:30

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#7 2024-01-16 10:05:39

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#8 2024-01-17 08:45:11

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#9 2024-01-17 18:27:30

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#10 2024-01-17 19:04:21

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

#11 2024-01-17 19:59:12

Re: [SOLVED] Secure Boot: I don't understand the benefit of shimx64

Board footer