heads VS sbupdate

I downloaded the VGA ROM for my Thinkpad W530 for both the Intel IGPU and Nvidia Quadro K1000M using this and configured the build config to use them with the correct PCI ports (8086,0166 10de,0ffc). Everything works fine except the output for both the VGA and the mini DP port. Does anyone have any ideas of what I could be missing here?

You may be interested in Heads, which is available on Purism laptops under the name PureBoot. Though this really needs a coreboot-capable machine, I think, and isn't something you can just add to your existing UEFI boot chain.

You don't need to encrypt anything to verify those images, you just need to sign them. See how Heads does this.

https://github.com/osresearch/heads

Unfortunately there is also the Heads secure firmware: https://osresearch.net/ as well. Otherwise my vote would go to Heads. Liive OS could be pretty hard to optimize in a search engine, they'll think it's misspelled. Could call it "Miles" and just never ack the reference...

Heads, https://osresearch.net/

If you worried about malicious changes, there is the write lock protection feature in coreboot that prevents internal flashing. This would require you to flash externally whenever you want to update coreboot. If worried someone will also flash your BIOS externally, you may want to look into Heads

I use sbupdate [0] to build the unified kernel image and to sign it with my keys. It's run by a hook in the arch's package manager whenever the kernel, the initrd or the firmware images change. I saw the other day that systemd recently got an utility to do this, but I've never looked into that. sbupdate has been working fine for me for several years now.

It doesn't store a new key in the uefi, it signs the new image with the key that uefi already knows about.

See [1] for the whole setup and [2] for the signing part specifically.

[0] https://github.com/andreyv/sbupdate

[1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

[2] https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

Here is where different systems will fork. On Arch there is a pacakge sbupdate where it automatically generate unified kernel images using pacman hooks and I use systemd-boot (which must be signed by your keys) to load it.

I really think it's easy enough. You create your keys, put them into /etc/efi-keys, enroll them into your UEFI by whatever method you prefer, install sbupdate-git and you're done... You need to run sbupdate manually once after install, everything else works automatically through hooks.

Ah, sbupdate does that very well; it embeds the kernel image, initramfs and the UEFI boot image into a unified signed image. I presume this signed image should then be further encrypted?

Check out https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot and https://github.com/andreyv/sbupdate

For the last part, check out https://github.com/andreyv/sbupdate . Linked also from arch wiki, so not some completely random solution. Its for creating unified kernel images, including the initramfs, microcode and so on. This package is then signed for secureboot, and can be loaded using EFISTUB for example. This prevents attacks against initramfs or some other things on /boot, if unencrypted. I haven't come around to test it myself, but I think its a neat solution, and with proper secure boot (and password protected firmware), a reasonable protection against evil maid attacks.

I am using secure boot with custom keys, a fully encrypted root btrfs partition with /boot on it, with swap also encrypted with hibernation support. The only non-encrypted partition is the EFI partition with boot images signed with https://github.com/andreyv/sbupdate (look up "direct booting").