How to sign a locally compiled kernel so it can be booted with UEFI.

[stan]

I compiled a fedora kernel locally.  When I tried to boot it in UEFI,
it failed because it wasn't signed.  Which it is supposed to.  

I then searched and found the procedure for generating local keys
using openssl, getting the public key into mok, generating the
certificate, the pkcs12 structure, putting it in the pesign database,
signing the kernel, and rebooting.

It still doesn't boot.  Is there anyone here who has a successful
technique for signing a locally compiled kernel so it will boot under
UEFI?

I found some extreme measures like taking over all signing, but I think
it is a little early for those.  And, of course, I could turn off
secure boot, but I'll give it a chance before doing that.

Thanks.

[Gordon Messmer]

On 6/10/19 11:39 AM, stan via users wrote:
>  It still doesn't boot.  Is there anyone here who has a
> successful
>  technique for signing a locally compiled kernel so it will boot under
>  UEFI? 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...

Red Hat has a guide for this, but some details vary from motherboard to 
motherboard.

[stan]

On Mon, 10 Jun 2019 18:22:49 -0700
Gordon Messmer <gordon.messmer(a)gmail.com&gt; wrote:

>  On 6/10/19 11:39 AM, stan via users wrote:
>  > It still doesn't boot.  Is there anyone here who has a successful
>  > technique for signing a locally compiled kernel so it will boot
>  > under UEFI?  
>  
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
>  
>  Red Hat has a guide for this, but some details vary from motherboard
>  to motherboard. 
Thanks.  According to that, not only the kernel has to be signed, but
all the modules that the kernel will load.  Whew!  That is a real
hurdle, and a show stopper, unless there is a process to do that during
build. I'll have to investigate.  It is probably why my custom kernel
wouldn't boot, as I didn't sign any modules, only the kernel vmlinuz.

[Samuel Sieb]

On 6/10/19 6:57 PM, stan via users wrote:
>  Thanks.  According to that, not only the kernel has to be signed,
> but
>  all the modules that the kernel will load.  Whew!  That is a real
>  hurdle, and a show stopper, unless there is a process to do that during
>  build. I'll have to investigate.  It is probably why my custom kernel
>  wouldn't boot, as I didn't sign any modules, only the kernel vmlinuz. 
You also used mokutil to load the key in the firmware?  You should have 
received a prompt at boot to accept it.

[stan]

On Tue, 11 Jun 2019 00:46:20 -0400
Samuel Sieb <samuel(a)sieb.net&gt; wrote:

>  On 6/10/19 6:57 PM, stan via users wrote:
>  > Thanks.  According to that, not only the kernel has to be signed,
>  > but all the modules that the kernel will load.  Whew!  That is a
>  > real hurdle, and a show stopper, unless there is a process to do
>  > that during build. I'll have to investigate.  It is probably why my
>  > custom kernel wouldn't boot, as I didn't sign any modules, only the
>  > kernel vmlinuz.  
>  
>  You also used mokutil to load the key in the firmware?  You should
>  have received a prompt at boot to accept it. 
Yes, I did, and it accepted it.  When I run pesign -S -i on the signed
kernel it shows that it was signed, 

 pesign -S -i vmlinuz-5.2.0-0.rc3.git3.1.20190609.fc31.x86_64
---------------------------------------------
certificate address is 0x7f254f09c4a8
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Red Hat Test Certificate
No signer email address.
Signing time: Sun Jun 09, 2019
There were certs or crls included.
---------------------------------------------
certificate address is 0x7f254f09cfa0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Organization signing key
The signer's email address is e-mail address
Signing time: Mon Jun 10, 2019
There were certs or crls included.

Based on things I've discovered while building a new kernel, I think
that the problem might be a missing ISO8859-1 module in the kernel.
When I boot the custom kernel with secure boot turned off, it fails
because it cannot load /boot/efi because it is missing that module.
When I add it to the build, the boot succeeds.  I wonder if the error
message is misleading, and it is actually failing because it can't get
to the information in the /boot/efi directory that it needs to check
the signature.  Will be checking that after I sign the new kernel that
successfully boots.  I'm thinking of creating new keys now that I am
more familiar with the process, keys I specify rather than accepting
defaults.  Maybe writing a simple script for creating and signing.

The other thing that is a positive, is that the kernel automatically
signs all modules during build if configured to do so, which I have, so
I don't have to worry about that. I'm using sha512, while the stock
kernels use sha256, but that shouldn't make a difference, as long as
the validation takes its cue from the kernel declaration, rather than
being hard coded.

SOLVED: Re: How to sign a locally compiled kernel so it can be booted with UEFI.

[stan]

On Mon, 10 Jun 2019 22:24:11 -0700
stan via users <users(a)lists.fedoraproject.org&gt; wrote:

>  The other thing that is a positive, is that the kernel automatically
>  signs all modules during build if configured to do so, which I have,
>  so I don't have to worry about that. I'm using sha512, while the stock
>  kernels use sha256, but that shouldn't make a difference, as long as
>  the validation takes its cue from the kernel declaration, rather than
>  being hard coded. 
The solution is that the kernel is already signed by the build process,
when it is built from the Fedora kernel spec.  The problem wasn't
the signing, it was a missing code page for 8859-1.  This is the
default code page for vfat in the kernel, so it couldn't read
the /boot/efi partition.  Once I added the code page, the boot succeeds
as UEFI.   I'm going to try changing that default to utf-8 so I don't
have to keep the 8859-1 code page.

SOLVED: Re: How to sign a locally compiled kernel so it can be booted with UEFI.

[stan]

On Tue, 11 Jun 2019 08:39:12 -0700
stan <upaitag(a)zoho.com&gt; wrote:

>  The solution is that the kernel is already signed by the build
>  process, when it is built from the Fedora kernel spec.  The problem 
This signature is the problem, as it is a red hat signature and has to
be removed.  That was the other part of the solution.

>  wasn't the signing, it was a missing code page for 8859-1.  This
> is
>  the default code page for vfat in the kernel, so it couldn't read
>  the /boot/efi partition.  Once I added the code page, the boot
>  succeeds as UEFI.   I'm going to try changing that default to utf-8
>  so I don't have to keep the 8859-1 code page. 
The code page was a legitimate issue, but only part of the issue.
When I tried utf-8 for the /boot/efi partition booting failed. There
must be some hardcoded linking of vfat and ISO8859 somewhere.  I don't
think there is a technical reason precluding the use of utf-8 with vfat.

For the process that actually worked to yield a signed custom kernel,
see additional information in

https://bugzilla.redhat.com/show_bug.cgi?id=1719930

SOLVED: Re: How to sign a locally compiled kernel so it can be booted with UEFI.

[Chris Adams]

Once upon a time, stan via users <users(a)lists.fedoraproject.org&gt; said:
>  On Tue, 11 Jun 2019 08:39:12 -0700
>  stan <upaitag(a)zoho.com&gt; wrote:
>  > wasn't the signing, it was a missing code page for 8859-1.  This is
>  > the default code page for vfat in the kernel, so it couldn't read
>  > the /boot/efi partition.  Once I added the code page, the boot
>  > succeeds as UEFI.   I'm going to try changing that default to utf-8
>  > so I don't have to keep the 8859-1 code page.
>  
>  The code page was a legitimate issue, but only part of the issue.
>  When I tried utf-8 for the /boot/efi partition booting failed. There
>  must be some hardcoded linking of vfat and ISO8859 somewhere.  I don't
>  think there is a technical reason precluding the use of utf-8 with vfat. 
The UEFI standard defines its own filesystem format that is a fixed
subset of FAT32.  Only ASCII and UCS-2 character encodings are
officially supported for long filename support.  Windows FAT32 includes
UTF-16 for LFN, but that's not supported in UEFI (UTF-8 is not even
mentioned).

-- 
Chris Adams <linux(a)cmadams.net&gt;

SOLVED: Re: How to sign a locally compiled kernel so it can be booted with UEFI.

[stan]

On Wed, 12 Jun 2019 14:03:04 -0500
Chris Adams <linux(a)cmadams.net&gt; wrote:

>  Once upon a time, stan via users
> <users(a)lists.fedoraproject.org&gt; said: 
>  > The code page was a legitimate issue, but only part of the
> issue.
>  > When I tried utf-8 for the /boot/efi partition booting failed. There
>  > must be some hardcoded linking of vfat and ISO8859 somewhere.  I
>  > don't think there is a technical reason precluding the use of utf-8
>  > with vfat.  
>  
>  The UEFI standard defines its own filesystem format that is a fixed
>  subset of FAT32.  Only ASCII and UCS-2 character encodings are
>  officially supported for long filename support.  Windows FAT32
>  includes UTF-16 for LFN, but that's not supported in UEFI (UTF-8 is
>  not even mentioned).
>   
Thanks, that clears things up.