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

Open
opened 2024-09-12 00:38:21 +00:00 by JulianGodd · 4 comments
JulianGodd commented 2024-09-12 00:38:21 +00:00 (Migrated from github.com)

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.

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](https://github.com/user-attachments/assets/165417b3-5e7f-4386-afbf-5f8bc2575a4a) 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](https://github.com/Foxboron/sbctl/issues/67#issuecomment-842525769)) 5. Booted system a. Verified system is in setup mode ![verified_setup_mode](https://github.com/user-attachments/assets/6d459430-cf29-48e0-972b-ea1812e060fa) 6. Attempted to enroll-keys ![enroll-keys_error](https://github.com/user-attachments/assets/5802feca-4af3-486e-bd2d-f67cfe5bfd9d) 7. Ran chattr -i on files from error 8. Succeeded in enrolling keys ![enroll-keys_success](https://github.com/user-attachments/assets/3b0325ab-c1a2-4bd7-a44f-383c42dca127) a. `sbctl status` after enrolling keys ![setup_disabled_after_enroll-keys_success](https://github.com/user-attachments/assets/58bf6bb7-adff-4fca-a380-57dbc6faf602) b. Ran `sbctl verify` ![sbctl_verify](https://github.com/user-attachments/assets/e20cec23-9dae-43bd-b2f3-d3eb6475419f) 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 2024-10-05 12:24:49 +00:00 (Migrated from github.com)

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.

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 2024-10-30 23:41:37 +00:00 (Migrated from github.com)

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!

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](https://github.com/nix-community/lanzaboote/blob/master/docs/QUICK_START.md#checking-that-your-machine-is-ready-for-secure-boot-enforcement). 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 2024-11-03 20:10:43 +00:00 (Migrated from github.com)

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!

> 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!
Sh3Rm4n commented 2025-03-17 12:32:45 +00:00 (Migrated from github.com)

I had similar problems (dell precision 3590), at least the same error when enrolling (6.) and following the quick start installation steps but using sudo sbctl enroll-keys --microsoft --ignore-immutable worked. Maybe this helps.

I had similar problems (dell precision 3590), at least the same error when enrolling (6.) and following the quick start installation steps but using `sudo sbctl enroll-keys --microsoft --ignore-immutable` worked. Maybe this helps.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: raito/lanzaboote#389
No description provided.