Github messages for voidlinux
 help / color / mirror / Atom feed
From: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [ISSUE] [CLOSED] EFI Secure Boot Build Support
Date: Fri, 29 Apr 2022 04:13:13 +0200	[thread overview]
Message-ID: <20220429021313.ARw1Y17fyOD6dQLPm-gOKcMYdbo0MNLuyz-mYw65dug@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-12495@inbox.vuxu.org>

[-- 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



  parent reply	other threads:[~2022-04-29  2:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-16 18:33 [ISSUE] " voidlinux-github
2019-06-16 18:36 ` voidlinux-github
2019-06-16 19:34 ` voidlinux-github
2019-06-17 18:24 ` voidlinux-github
2019-06-17 18:39 ` voidlinux-github
2019-06-18 18:55 ` voidlinux-github
2019-06-18 18:56 ` voidlinux-github
2019-06-18 18:57 ` voidlinux-github
2019-06-20 11:17 ` voidlinux-github
2019-06-20 11:20 ` voidlinux-github
2019-06-20 11:22 ` voidlinux-github
2019-06-20 11:26 ` voidlinux-github
2019-06-20 22:38 ` voidlinux-github
2019-06-20 22:39 ` voidlinux-github
2019-06-20 22:40 ` voidlinux-github
2019-06-21  5:29 ` voidlinux-github
2019-07-01 15:58 ` voidlinux-github
2019-10-03 22:10 ` voidlinux-github
2020-07-27 14:20 ` unixandria-xda
2020-07-27 14:57 ` sgn
2020-07-28  5:50 ` ericonr
2020-07-28  6:02 ` sgn
2022-04-15  2:12 ` github-actions
2022-04-29  2:13 ` github-actions [this message]
2022-07-28  4:47 ` dm17
2023-01-09  6:27 ` thegarlynch
2024-02-11 15:08 ` Izooc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220429021313.ARw1Y17fyOD6dQLPm-gOKcMYdbo0MNLuyz-mYw65dug@z \
    --to=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).