search

nix-community / lanzaboote

Secure Boot for NixOS [maintainers=@blitz @raitobezarius @nikstur]
GNU General Public License v3.0
934 stars 44 forks source link

Unable to boot with secure boot enabled after installing lanzaboote on optiplex 7070 #389

Open JulianGodd opened 2 months ago

JulianGodd commented 2 months ago

After installing lanzaboote on a Dell optiplex 7070 micro, I'm unable to boot with secure boot enabled due to the kernel hash not matching: kernel_hash_doesnt_match

In the interest of brevity I've excluded some photos of the bios which I am happy to share if it helps debug. Also excluded is my exact nix configuration as it is barely different from the flake provided in the quick start guide. I am also happy to provide this if I made the wrong call not including it. Command screenshots are taken on another computer connected via ssh.

Here's a rough sequence of events:

  1. Used flake for lanzaboote a. rebuilt system with flake

  2. Ran sudo sbctl create-keys

  3. Rebooted to bios

  4. Enabled secure boot, expert key management (custom mode), setup mode (dell seems to call this audit mode)

  5. Booted system a. Verified system is in setup mode verified_setup_mode

  6. Attempted to enroll-keys enroll-keys_error

  7. Ran chattr -i on files from error

  8. Succeeded in enrolling keys enroll-keys_success a. sbctl status after enrolling keys setup_disabled_after_enroll-keys_success b. Ran sbctl verify sbctl_verify At some point I tried running sbctl sign on both kernels as they were initially unsigned in attempt to fix errors

  9. Unable to boot due to error pictured at the top

I've also tried the --microsoft and --append flags when enrolling keys.

If I missed anything I'm happy to elaborate. Thanks for any help.

kuflierl commented 1 month ago

From my (somewhat limited) understanding of lanzaboote, only the boot stub (a slim binary whose only job it is to boot with certain compile time hard coded boot parameters) is signed. The stub has baked in hashes of the kernel and initramfs. Its highly possible that by signing those kernels you just changed the sha256 hashes and borked your boot. Also if i remember correctly you really aren't supposed to manipulate files that originate from /nix/store.

This on first glance doesn't seem like a bios error, but an error from the stub complaining about a hash mismatch.

JulianGodd commented 4 weeks ago

This works! Thanks for the help! Sorry for the delay in responding, I didn't have immediate access to a test environment.

Do you know where I can read more about this? I'd love to update the quick start to mention this but I lack knowledge. This seems related to files ending in bzImage.efi needing to not be signed.

Are you aware of any way to undo signing a kernel or do I need a fresh install? It seems to me that sbctl doesn't have a command for this.

Thanks again!

kuflierl commented 3 weeks ago

Are you aware of any way to undo signing a kernel or do I need a fresh install? It seems to me that sbctl doesn't have a command for this.

You should be able to replace the file from its original source in the nix store (if you also replaced it there there are commands to redo a derivation.

A simple solution could be to just enter your install with nixOS-enter and then doing a nixOS-switch since a new kernel version should be available.

Since this is nixOS, it might be even less of a hassle to reinstall tho.

Thanks again!