[ISSUE] EFI Secure Boot Build Support

[ISSUE] EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

New issue by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495
Description: Secure boot using EFI means that the motherboard's firmware verifies
the binaries it loads to prevent unauthorised binaries from being used
tot boot the system. Secure boot using EFI isn't too tricky to set up,
but there are a few ways one can go about doing it.

For an overview of the process of using secure boot via EFI, I can
recommend the following two pages that I find highly informative:

Managing EFI Boot Loaders for Linux: Dealing with Secure Boot
https://www.rodsbooks.com/efi-bootloaders/secureboot.html

Secure Boot with GRUB 2 and signed Linux
https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd

The first link gives an overview of how the process generally works
and talks about the use of shim loaders, while the second link shows
how to use an EFI signed Grub to load a GPG signed Linux.

Personally, I use the second approach. I have replaced the keys in my
motherboard with my own and have signed a Grub binary using adapted
versions of the scripts in the second link. I then use GPG to sign the
kernel and initramfs.

It shouldn't be too much work setting up kernel hooks that perform the
signing. The issue might be deciding if a single model should be
supported or whether different options should be provided via
configurability.

I personally, manually perform these steps:
1. Generating and store EFI keys in motherboard
1.1 Generate EFI keys, using keygen.sh in the linked tar ball
1.2 Store keys in motherboard by loading them in the EFI GUI
2. Creating a signed Grub 
2.1 Create a password to put into grub-initial.cfg using gpasswd.
2.2 Generate a stand-alone Grub with my GPG public key compiled in and sign it using EFI keys. This is done with generate-grub.sh in the linked tarball.
3. Sign my existing kernels, initramfs and Grub boot menu config in /boot using sign.sh in the linked tarball.
4. Enable secure boot

(All scripts are slightly adapted from the previous two links.)

When updating the kernel I manually rerun step 3.

To minimise work to get a working example, one could maybe start by supporting the model described above and then add additional support later if it is deemed necessary. Myself, I haven't tried using the shim loader nor the EFI stub. If Void wishes to pre-sign binaries, I guess the shim route would be the one to go.

The signing scripts I use: https://www.lysator.liu.se/~kempe/secure-boot.tar.gz

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-502475458
Comment:
I can add that I'm willing to do coding work on this if a clear way forward can be chosen. This to not waste time doing work that would be thrown away.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

New comment by ackalker on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-502479482
Comment:
@andkem [partly OT} Nice to see someone willing to work on EFI. Would you be willing to exchange ideas about fixing (other) kernel install hooks aswell?

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-502797009
Comment:
@ackalker, sure, I wouldn't mind. Although I've got quite a lot on my plate so I can't promise I'll do any astounding amounts of coding.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 158 bytes --]

New comment by ackalker on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-502802480
Comment:
@andkem Thanks!

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-503266530
Comment:
I have a concrete suggestion for solving this.

1. We can modify the grub template and add a grub-x86_64-secure-boot_package() section that carries dependencies on the EFI signing tools. 
2. This package could install a script in /usr/bin called grub-mksigned that takes a GPG ID and the path to EFI keys as well as the path to an initial Grub config. An example configuration could be provided under /usr/share/examples/grub
3. To generate EFI keys, a script called grub-mkefikeys (names are mere suggestions) could be provided that takes a path where it puts generated keys. It could also output instructions on importing them into the EFIs key storage (pretty much the keygen.sh script in the linked tarball).

The Grub generation only has to be done once (unless you change keys) and I don't feel it would be reasonable to have it as a manual step to be able to provide your own keys and custom configuration.

As for the kernel, in this model it would be signed using the correct GPG-key. One could provide a post-install hook that runs after Grub configuration has been generated and gets the GPG ID from a configuration file under /etc/defaults and signs kernel, initramfs and Grub config using that key.

One thing I'm a bit unsure about is how to modify the generated Grub configuration without being too invasive as it could be desierable to have the --unrestricted option on a kernel you want to boot to avoid having to type passwords twice.

This is simply an attempt at a concrete suggestion if one wishes to use the Grub model to give us more of a seed for discussion.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-503266530
Comment:
I have a concrete suggestion for solving this.

1. We can modify the grub template and add a grub-x86_64-secure-boot_package() section that carries dependencies on the EFI signing tools. 
2. This package could install a script in /usr/bin called grub-mksigned that takes a GPG ID and the path to EFI keys as well as the path to an initial Grub config. An example configuration could be provided under /usr/share/examples/grub
3. To generate EFI keys, a script called grub-mkefikeys (names are mere suggestions) could be provided that takes a path where it puts generated keys. It could also output instructions on importing them into the EFIs key storage (pretty much the keygen.sh script in the linked tarball).

The Grub generation only has to be done once (unless you change keys) and I don't feel it would be reasonable to have it as a manual step to be able to provide your own keys and custom configuration.

As for the kernel, in this model it would be signed using the correct GPG-key. One could provide a post-install hook that runs after Grub configuration has been generated and gets the GPG ID from a configuration file under /etc/defaults and signs kernel, initramfs and Grub config using that key.

One thing I'm a bit unsure about is how to modify the generated Grub configuration without being too invasive as it could be desierable to have the --unrestricted option on a kernel you want to boot to avoid having to type passwords twice.

This is simply an attempt at a concrete suggestion if one wishes to use the Grub model to give us more of a seed for discussion and as such feel free to shoot it down or improve it.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-503266530
Comment:
I have a concrete suggestion for solving this.

1. We can modify the grub template and add a grub-x86_64-secure-boot_package() section that carries dependencies on the EFI signing tools. 
2. This package could install a script in /usr/bin called grub-mksigned that takes a GPG ID and the path to EFI keys as well as the path to an initial Grub config. An example configuration could be provided under /usr/share/examples/grub
3. To generate EFI keys, a script called grub-mkefikeys (names are mere suggestions) could be provided that takes a path where it puts generated keys. It could also output instructions on importing them into the EFIs key storage (pretty much the keygen.sh script in the linked tarball).

The Grub generation only has to be done once (unless you change keys) and I don't feel it would be unreasonable to have it as a manual step to be able to provide your own keys and custom configuration.

As for the kernel, in this model it would be signed using the correct GPG-key. One could provide a post-install hook that runs after Grub configuration has been generated and gets the GPG ID from a configuration file under /etc/defaults and signs kernel, initramfs and Grub config using that key.

One thing I'm a bit unsure about is how to modify the generated Grub configuration without being too invasive as it could be desierable to have the --unrestricted option on a kernel you want to boot to avoid having to type passwords twice.

This is simply an attempt at a concrete suggestion if one wishes to use the Grub model to give us more of a seed for discussion and as such feel free to shoot it down or improve it.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

New comment by congdanhqx on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-503986212
Comment:
Actually, we have the facility to enable EFI boot already with:

https://github.com/void-linux/void-packages/blob/master/srcpkgs/sbsigntool/template

But this one is only tested on booting directly from efi,
I'm running that one on my laptop, now.

The part to generate key and install it into UEFI is still missing, though.
---
I'm not grub's user, but I'm happy to take the work for it.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

New comment by congdanhqx on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-503986212
Comment:
Actually, we have the facility to enable EFI boot already with:

https://github.com/void-linux/void-packages/blob/master/srcpkgs/sbsigntool/template
and
https://github.com/void-linux/void-packages/blob/master/srcpkgs/efitools/template

But this one is only tested on booting directly from efi,
I'm running that one on my laptop, now.

The part to generate key and install it into UEFI is still missing, though.
When I create those packages, I thought it might be a better idea to leave it to user,
I could write an `INSTALL` script for it, if you guys think it's good idea.

-----

I'm not grub's user, but I'm happy to take the work for it.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

New comment by congdanhqx on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-503986212
Comment:
Actually, we have the facility to enable EFI boot already with:

https://github.com/void-linux/void-packages/blob/master/srcpkgs/sbsigntool/template
and
https://github.com/void-linux/void-packages/blob/master/srcpkgs/efitools/template

But this one is only tested on booting directly from efi,
I'm running that one on my laptop, now.
Anyway, with `sbsigntool`, only the kernel is signed, the initrd isn't signed.
I'll take a another look for it.

The part to generate key and install it into UEFI is still missing, though.
When I create those packages, I thought it might be a better idea to leave it to user,
I could write an `INSTALL` script for it, if you guys think it's good idea.

-----

I'm not grub's user, but I'm happy to take the work for it.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 165 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-503988588
Comment:
Please go ahead, thanks

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-504224383
Comment:
@congdanhqx, I looked at those recipes and the hooks that were in place, but didn't consider them a complete secure boot solution since they don't, as you point out, sign the initrd or provide tools for actually generating keys. There were some block of the hook that had a comment stating it was untested, iirc. Sadly I'm away from my computer for the week-end so I cannot check.

For a secure boot solution that isn't trivial (well almost) to circumvent we need both kernel and initrd to be signed. We also need the root file system to either be signed and read only, ex. using dm-verity, or encrypted. I'd suggest that telling people to encrypt should be enough, since a read only root won't really work with Void the way it is currently structured.

The main point to make for using Grub instead of a pure EFI boot is that we could support having the boot partition encrypted. Even with signed binaries, there are attacks that can be mitigated by having it encrypted. An example could be injecting data into the partition that you are tricked to sign.

If you'd like to start working on this, congdanhqx, I don't mind. I'd also be glad to cooperate, review and discuss if you want.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-504224383
Comment:
@congdanhqx, I looked at those recipes and the hooks that were in place, but didn't consider them a complete secure boot solution since they don't, as you point out, sign the initrd or provide tools for actually generating keys. There was also some block of the hook that had a comment stating it was untested, iirc. Sadly I'm away from my computer for the week-end so I cannot check.

For a secure boot solution that isn't trivial (well almost) to circumvent we need both kernel and initrd to be signed. We also need the root file system to either be signed and read only, ex. using dm-verity, or encrypted. I'd suggest that telling people to encrypt should be enough, since a read only root won't really work with Void the way it is currently structured.

The main point to make for using Grub instead of a pure EFI boot is that we could support having the boot partition encrypted. Even with signed binaries, there are attacks that can be mitigated by having it encrypted. An example could be injecting data into the partition that you are tricked to sign.

If you'd like to start working on this, congdanhqx, I don't mind. I'd also be glad to cooperate, review and discuss if you want.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-504224383
Comment:
@congdanhqx, I looked at those recipes and the hooks that were in place, but didn't consider them a complete secure boot solution since they don't, as you point out, sign the initrd or provide tools for actually generating keys. There was also some block of the hook that had a comment stating it was untested, iirc. Sadly I'm away from my computer for the week-end so I cannot check.

For a secure boot solution that isn't trivial (well almost) to circumvent we need both kernel and initrd to be signed. We also need the root file system to either be signed and read only, ex. using dm-verity, or encrypted. I'd suggest that telling people to encrypt should be enough, since a read only root won't really work with Void the way it is currently structured.

The main point to make for using Grub instead of a pure EFI boot is that we could support having the boot partition encrypted. Even with signed binaries, there are attacks that can be mitigated by having it encrypted. An example could be injecting data into the partition that you are then tricked to sign.

If you'd like to start working on this, congdanhqx, I don't mind. I'd also be glad to cooperate, review and discuss if you want.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

New comment by congdanhqx on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-504295085
Comment:
On June 20, 2019 10:38:25 PM UTC, andkem <notifications@github.com> wrote:

>they don't, as you point out, sign the initrd or provide tools for

The sbsigntools couldn't sign the initrd itself, it can sign the efi executable (EFIStub enabled kerbel, refind, grub) only.

If I understand other comments correctly,  grub signs kernel and initrd with gpg.

>actually generating keys.

The efi signing-key generation is done by openssl and efitools, IIRC, I didn't put the key generator script into the installation because I weren't sure what should be done with the manufacture's key that's existed in EFI firmware? Should we concatenate that key with our newly generated key or we should simply throw it away or we should give users a choice?

I don't know about the key generation for GRUB, is it a gpg key? What is our expectation for this? Or we should skip signing if there're no gpg key?

>There were some block of the hook that had a
>comment stating it was untested, iirc.

The untested part is about the EFI_SIGN_ENGINE,
That option is used for some specific EFI firmwares,
I don't have those firmwares, hence, I couldn't test.

>for the week-end so I cannot check.
>
>For a secure boot solution that isn't trivial (well almost) to
>circumvent we need both kernel and initrd to be signed. We also need
>the root file system to either be signed and read only, ex. using
>dm-verity, or encrypted. I'd suggest that telling people to encrypt
>should be enough, since a read only root won't really work with Void
>the way it is currently structured.
>
>The main point to make for using Grub instead of a pure EFI boot is
>that we could support having the boot partition encrypted. Even with
>signed binaries, there are attacks that can be mitigated by having it

Agree, different threat models have different mitigations.



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-507325213
Comment:
> On June 20, 2019 10:38:25 PM UTC, andkem ***@***.***> wrote:
> they don't, as you point out, sign the initrd or provide tools for
> The sbsigntools couldn't sign the initrd itself, it can sign the efi executable (EFIStub enabled kerbel, refind, grub) only.
> 

I think it should be possible to do a setup where you verify everything using EFI, but I haven't tried it so I don't know how difficult it is. I was merely pointing out that parts for doing all the signing is missing.

> If I understand other comments correctly,  grub signs kernel and initrd with gpg.
> actually generating keys.

Grub doesn't sign the kernel nor the initrd, that is done using the normal gpg2 util. Grub only verifies the signature using the key compiled into it, but I guess that is what you meant.

> The efi signing-key generation is done by openssl and efitools, IIRC, I didn't put the key generator script into the installation because I weren't sure what should be done with the manufacture's key that's existed in EFI firmware? Should we concatenate that key with our newly generated key or we should simply throw it away or we should give users a choice?
> 

I would suggest that the user is asked if he wishes to create a backup of the built-in keys. That way they could be restored later. We will likely not be able to automate the installation of new keys in the motherboard. We could print a message giving guidance as to which files should be imported.


> I don't know about the key generation for GRUB, is it a gpg key? What is our expectation for this? Or we should skip signing if there're no gpg key?

The GPG keys is generated like one normally does with GPG. I would suggest that we ask the user to generate a key, possibly printing the command he needs to execute and then prompts for entering the ID of the key the user wishes to use. It could be as simple as executing gpg2 --full-generate-key and following the instructions, I'd suggest a 4096 RSA key.

Without actually signing using a GPG key, the process is pretty pointless.

And sorry for the tardy reply, I was away and didn't really have access to my computer.

Re: EFI Secure Boot Build Support

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

New comment by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-538148785

Comment:
I realised that my computer's motherboard allowed the removal of secure boot signatures by doing a simple reset of the EFI via the on-board jumper. Because of this I consider secure boot utterly broken on my system and subsequently lost interest in this issue.

I wouldn't mind if this issue were closed.

Re: EFI Secure Boot Build Support

[unixandria-xda]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

New comment by unixandria-xda on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-664425591

Comment:
 Any news? I'm looking to dualboot and my windows setup heavily depends on secure boot

Re: EFI Secure Boot Build Support

[sgn]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-664447632

Comment:
> Any news? I'm looking to dualboot and my windows setup heavily depends on secure boot

It's very unlikely that _I_ will contact MSFT to sign our shim for secure boot.

I recommend this guide instead https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC

I would spend sometime to co-ordinate with @ericonr for Void specific guide, though.

Re: EFI Secure Boot Build Support

[ericonr]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-664792246

Comment:
Signing the shim is a pain, requires payment, and then I believe we'd also have to sign the kernel *and* modules, which is another source of pain, so I don't think we should go that route.

@unixandria-xda  From my experience, the easiest route for Secure Boot is simply to not depend on GRUB:

- create SB keys (using openssl commands or something like https://github.com/Foxboron/sbctl - which unfortunately doesn't have a release yet)
- configure dracut for UEFI bundle generation (using #22484, manual configuration or something like https://github.com/zdykstra/zfsbootmenu - this last one is shipped on Void): this will create a bundle that contains the kernel, the cmdline, and the initramfs
- add the `secureboot_*` options to your dracut config, so dracut can sign the bundle at creation time; or extend the sbsigntool hook to sign UEFI bundles (#23688 ?); or create a sbctl hook to sign them (not supported yet)
- boot into the UEFI bundle directly (could have efibootmgr integration?) or into something like rEFInd, whose `refind-install` script can sign the refind executable

The only part that I don't understand much about is enrolling keys, because I do it through my own firmware.

Re: EFI Secure Boot Build Support

[sgn]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-664795753

Comment:
On 2020-07-27 22:50:51-0700, Érico Nogueira Rolim <notifications@github.com> wrote:
> Signing the shim is a pain, requires payment, and then I believe we'd also have to sign the kernel *and* modules, which is another source of pain, so I don't think we should go that route.
> 
> @unixandria-xda  From my experience, the easiest route for Secure Boot is simply to not depend on GRUB:
> 
> - create SB keys (using openssl commands or something like https://github.com/Foxboron/sbctl - which unfortunately doesn't have a release yet)
> - configure dracut for UEFI bundle generation (using #22484, manual

And #22484 is expected to be merged, soon.

> configuration or something like
> https://github.com/zdykstra/zfsbootmenu - this last one is shipped
> on Void): this will create a bundle that contains the kernel, the
> cmdline, and the initramfs

> - add the `secureboot_*` options to your dracut config, so dracut
> can sign the bundle at creation time; or extend the sbsigntool hook
> to sign UEFI bundles (#23688 ?); or create a sbctl hook to sign them

FWIW, #23688 will be updated once #22484 has been merged.

> (not supported yet)
> - boot into the UEFI bundle directly (could have efibootmgr
> integration?) or into something like rEFInd, whose `refind-install`
> script can sign the refind executable

In order to do secure boot with rEFInd,
we need to sign both rEFInd efi bootloader,
and the kernel.

The refind-install only sign rEFInd binaries and other binaries
shipped by them. We still need to sbsigntool/other hooks to sign newly
installed kernel.

> 
> The only part that I don't understand much about is enrolling keys, because I do it through my own firmware.

`efitools` provides userspace tools and `efitools-efi` package provides EFI binaries to do it.

-- 
Danh

Re: EFI Secure Boot Build Support

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by github-actions[bot] on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-1099786631

Comment:
Issues become stale 90 days after last activity and are closed 14 days after that.  If this issue is still relevant bump it or assign it.

Re: [ISSUE] [CLOSED] EFI Secure Boot Build Support

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]

Closed issue by andkem on void-packages repository

https://github.com/void-linux/void-packages/issues/12495

Description:
Secure boot using EFI means that the motherboard's firmware verifies
the binaries it loads to prevent unauthorised binaries from being used
tot boot the system. Secure boot using EFI isn't too tricky to set up,
but there are a few ways one can go about doing it.

For an overview of the process of using secure boot via EFI, I can
recommend the following two pages that I find highly informative:

Managing EFI Boot Loaders for Linux: Dealing with Secure Boot
https://www.rodsbooks.com/efi-bootloaders/secureboot.html

Secure Boot with GRUB 2 and signed Linux
https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd

The first link gives an overview of how the process generally works
and talks about the use of shim loaders, while the second link shows
how to use an EFI signed Grub to load a GPG signed Linux.

Personally, I use the second approach. I have replaced the keys in my
motherboard with my own and have signed a Grub binary using adapted
versions of the scripts in the second link. I then use GPG to sign the
kernel and initramfs.

It shouldn't be too much work setting up kernel hooks that perform the
signing. The issue might be deciding if a single model should be
supported or whether different options should be provided via
configurability.

I personally, manually perform these steps:
1. Generating and store EFI keys in motherboard
1.1 Generate EFI keys, using keygen.sh in the linked tar ball
1.2 Store keys in motherboard by loading them in the EFI GUI
2. Creating a signed Grub 
2.1 Create a password to put into grub-initial.cfg using gpasswd.
2.2 Generate a stand-alone Grub with my GPG public key compiled in and sign it using EFI keys. This is done with generate-grub.sh in the linked tarball.
3. Sign my existing kernels, initramfs and Grub boot menu config in /boot using sign.sh in the linked tarball.
4. Enable secure boot

(All scripts are slightly adapted from the previous two links.)

When updating the kernel I manually rerun step 3.

To minimise work to get a working example, one could maybe start by supporting the model described above and then add additional support later if it is deemed necessary. Myself, I haven't tried using the shim loader nor the EFI stub. If Void wishes to pre-sign binaries, I guess the shim route would be the one to go.

The signing scripts I use: https://www.lysator.liu.se/~kempe/secure-boot.tar.gz

Re: EFI Secure Boot Build Support

[dm17]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

New comment by dm17 on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-1197656354

Comment:
> Signing the shim is a pain, requires payment, and then I believe we'd also have to sign the kernel _and_ modules, which is another source of pain, so I don't think we should go that route.
> 
> @unixandria-xda From my experience, the easiest route for Secure Boot is simply to not depend on GRUB:
> 
> * create SB keys (using openssl commands or something like https://github.com/Foxboron/sbctl - which unfortunately doesn't have a release yet)
> * configure dracut for UEFI bundle generation (using [dracut: add EFI kernel hook #22484](https://github.com/void-linux/void-packages/pull/22484), manual configuration or something like https://github.com/zdykstra/zfsbootmenu - this last one is shipped on Void): this will create a bundle that contains the kernel, the cmdline, and the initramfs
> * add the `secureboot_*` options to your dracut config, so dracut can sign the bundle at creation time; or extend the sbsigntool hook to sign UEFI bundles ([sbsigntool: rewrite post-install kernel hook #23688](https://github.com/void-linux/void-packages/pull/23688) ?); or create a sbctl hook to sign them (not supported yet)
> * boot into the UEFI bundle directly (could have efibootmgr integration?) or into something like rEFInd, whose `refind-install` script can sign the refind executable
> 
> The only part that I don't understand much about is enrolling keys, because I do it through my own firmware.

Looks like a great start. Has anyone gone further with creating clear instructions for a secureboot / signed ZBM setup?

Re: EFI Secure Boot Build Support

[thegarlynch]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

New comment by thegarlynch on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-1375163384

Comment:
Will we put it in void docs ? or is it not complete solution yet

Re: EFI Secure Boot Build Support

[Izooc]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

New comment by Izooc on void-packages repository

https://github.com/void-linux/void-packages/issues/12495#issuecomment-1937780462

Comment:
> Will we put it in void docs ? or is it not complete solution yet

Would like an answer to this aswell. Been trying to fully encrypt system but realised encrypting boot is not possible (?) so the only way to prevent evil maid is secure boot. Correct me if I'm wrong though 😁