Skip to content
This repository has been archived by the owner on Feb 21, 2022. It is now read-only.

Boot failure on Debian 10 #6

Open
Snawoot opened this issue Jul 8, 2019 · 10 comments
Open

Boot failure on Debian 10 #6

Snawoot opened this issue Jul 8, 2019 · 10 comments
Assignees

Comments

@Snawoot
Copy link
Owner

Snawoot commented Jul 8, 2019

GRUB fails to validate kernel signature due to Debian bug introduced by Debian patches to grub. I'm seeking for a way to workaround it.

@Snawoot Snawoot self-assigned this Jul 8, 2019
@Snawoot
Copy link
Owner Author

Snawoot commented Jul 8, 2019

Patch submitted to Debian maintainer of grub package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906124#55

@Snawoot Snawoot pinned this issue Jul 9, 2019
@noahbliss
Copy link

noahbliss commented Dec 20, 2019

Still no updates it looks like? Would it be possible for us to use the package from Debian 9 in the meantime?

@Snawoot
Copy link
Owner Author

Snawoot commented Dec 20, 2019

Hello,

Debian grub2 package developers stopped responding any attempts to fix that.

I think it's much easier to apply patch from this thread to Debian 10 package source. Even if package will be overwritten by upcoming grub package updates, grub binary installed by linux-secureboot-kit will be unaffected.

Process should look like this:

  1. Enable deb-src repos in /etc/apt/sources.list
  2. apt-get install -y devscripts quilt
  3. apt-get build-dep grub2
  4. apt-get source grub2
  5. Enter into grub2 source directory under current directory and push new patch: https://wiki.debian.org/UsingQuilt#Making_a_new_patch
  6. Update version and add log message with a dch -i
  7. Run debuild -us -uc

@noahbliss
Copy link

Thanks for the info. Perhaps it wouldn't be a bad idea on Debian to forego trying to fix grub and just bypass it entirely using a single signed EFI that combines kernel and initramfs. I believe this is one such example: https://gist.github.com/zaxebo1/a17577390512bdea35a00d111dac8aa2

@noahbliss
Copy link

Made a thing to get around this limitation if you (or anyone else) were interested: https://github.com/noahbliss/mortar
Skirts the whole "broken grub" issue by just not using grub. 👍

@Snawoot
Copy link
Owner Author

Snawoot commented Mar 4, 2020

@noahbliss Thanks! That looks like a step up solution since it uses metered boot and TPM.

@noahbliss
Copy link

Hey @Snawoot I'm back. Any chance you could give me a hand with using the db cert/key to sign modules with DKMS/other method in mortar? With many distros starting to enforce lockdown mode with kernel 5.4+ this is becoming more of a priority for me to implement. Otherwise I may browse your code for inspiration if that's cool.

@Snawoot
Copy link
Owner Author

Snawoot commented Jun 22, 2020

@noahbliss

Hi! Sure!

It's possible to add signing hook into DKMS with POST_BUILD option in dkms.conf for module. And DKMS config can be overriden via config file in /etc/dkms/MODULE.conf. However, it's tricky, there are few difficulties to overcome:

  • Problem: Module config may have some POST_BUILD script already.
    • Solution: introduce script chaining. Dynamically create post-build script which performs signing actions as needed and invokes original POST_BUILD. This action can be performed in overriden DKMS config for module because it's last sourced file by DKMS and all necessary variables already defined. Snoop to old value and export new value with chained script.
  • Problem: Path to post-build script must be specified relative to build dir.
    • Solution: calculate relative suffix for root and concatenate it with path to temporary chained script.
  • Problem: Ubuntu and others may have patched DKMS with own signing functions which are running after build stage.
    • Solution: unset sign_build function from local DKMS config for module.
      • Problem: DKMS sources config file in a safe fashion (like subprocess with sandboxed script which exports only defined variable values). So, function override won't work.
        • Solution: detect it, and dump function override code straight into intermediate file with safe-sourcing results, which is sourced by DKMS directly.

Here is DKMS config override which is installed for each DKMS module into /etc/dkms/. Here is what it does:

  1. Calculates root path relative to build directory.
  2. Copies all required variables which already defined by module DKMS config (or other local overrides).
  3. Enforces stripping of built module.
  4. Composes new POST_BUILD script which does signatures and chains to original POST_BUILD script.
  5. Makes sign_build function of Ubuntu-patched DKMS a no-op function.

This "config" file contains nothing specific to linux-secureboot-kit project except path to db cert/key. It's in lines 81, 87, 92. You may use this hook right away in your project.

And there is another script which is responsible for installation of DKMS hooks. It just enumerates all modules installed via DKMS and symlinks DKMS config override with hook into /etc/dkms. I think only constant you need to modify in it is location of installed DKMS hook file (which was discussed above).

So, I think everything is ready and you may just add these files into your project with minor modifications.

If you'll have questions or need further assistance you may reach me directly:

@noahbliss
Copy link

Dang! Solid info. I'll give it some cycles and see where I land, thanks a ton!

@Snawoot
Copy link
Owner Author

Snawoot commented Oct 3, 2020

Centos 8 backported ugly linux-efi bugs from debian as well, so lsbk is unusable on it too.

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

No branches or pull requests

2 participants