On Fri, 02 Jul 2021 16:30:14 +1000
"Michael D. Setzer II via users" <users(a)lists.fedoraproject.org> wrote:
Thanks for the reply. Comments below
On 1 Jul 2021 at 18:35, Samuel Sieb wrote:
Subject: Re: Questions on creating RPM
Package??
To: users(a)lists.fedoraproject.org
From: Samuel Sieb <samuel(a)sieb.net>
Date sent: Thu, 1 Jul 2021 18:35:01 -0700
Send reply to: Community support for Fedora
users <users(a)lists.fedoraproject.org>
> On 2021-06-28 3:39 p.m., Michael D. Setzer II via users wrote:
> > That would then add options to the grub boot menu
> > similar to how memtest worked to add option. It
> > would load kernel image, and then g4l in ram to
> > run. Looked at memtest, but note that they don't
> > have an option with the EFI version, which was my
> > new question with shift to more systems using that?
> > Issues with creating signed kernels?
>
> I think memtest just didn't work with EFI at all, but there is also
> the more general problem of secure boot. You have to sign the
> kernel you use with a recognized key. Is it a special kernel or
> can you use the default Fedora kernel?
>
I've seen a page where memtest talked about the
problems they had with having to build special
kernels, and then issues with then having to get
new signed kernels every time they changed
anything, and thus decided it wasn't worth it?
I have memtest included with my g4l project.
It uses a kernel that is built from the source code of
kernel.org to include most disk and network
support to handle various hardware.
If you want to use a signed kernel, your public key has to be in the
UEFI key repository in order to use your kernel. That is, just like
Fedora does, you would need to add your public key to that repository.
Once it is added, you could sign all your newer kernels with the same
private key, and the public key would work for all of them. The
trouble is that people might not want to add a third party key to their
EFI key repository, because it has security implications.
Have actually looked at trying to use the fedora live
cd, but that is like a 2G file. It has most of the
support files, but would require adding a number of
little things and the primary script?? Haven't actual
tested it. Project uses busybox for much of the
support, but this would be using Fedora files
completely.
Yes, using a Fedora kernel will work, because the public key of the
private key it is signed with is already in the EFI key repository. It
has to be a stock kernel as you have no access to the private key that
Fedora uses to sign their kernels, so you cannot sign any kernel builds
you do with that key.
Recently had a machine with the EFI setup, and
wanted to run memtest on it, and couldn't. Ended
up using my g4l boot flash and just had to change
bios to allow the regular bios boot, but don't know if
uses want to do that?
I think this is the way to go. If they are using your recovery
program, they have already agreed that your kernel is secure. Turning
off secure boot to use it introduces no new security risk. I'm
assuming that they get it from the official Fedora repositories, so it
has been signed, and thus can be taken as unaltered.
I have personal instructions on how to create a public/private key
pair, put them in the proper places, and sign a kernel. I have posted
them to the devel list in the past, and could post them here if you
want. But, my recommendation is to go with the unsigned kernel
requiring secure boot to be turned off to boot it. And second would be
to use a Fedora signed kernel.