Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JulianGodd opened this issue Sep 12, 2024 · 3 comments

Comments

@JulianGodd
Copy link

JulianGodd commented Sep 12, 2024

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
Copy link
Contributor

kuflierl commented Oct 5, 2024

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
Copy link
Author

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
Copy link
Contributor

kuflierl commented Nov 3, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants