grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can't find a solution to a failed secure boot kernel loading


From: Dimitri John Ledkov
Subject: Re: Can't find a solution to a failed secure boot kernel loading
Date: Tue, 10 May 2022 15:43:18 +0100

On Tue, 10 May 2022 at 15:07, Łukasz Piątkowski <piontec@gmail.com> wrote:
>
> What I'm trying to do is to sign a mainline kernel built by ubuntu 
> (https://kernel.ubuntu.com/~kernel-ppa/mainline/) with my private key, that 
> is already enrolled to MOK, and boot it with Secure Boot.
>
> > the MOK key as generated by Ubuntu/Debian tooling, creates a signing 
> > certificate that self-limits itself to only support Kernel Module signing.
>
> OK, that explains why the key in `/var/lib/shim-signed/mok` doesn't work. 
> Still, I have created my own key as well (listed below for inspection, it has 
> code signing extension), enrolled that key in MOK and signed the ubuntu 
> mainline kernel (the kernel I'm trying to boot) with it. The result is 
> exactly the same. I was using exactly the same procedure a few ubuntu 
> editions back and it was definitely working. From what I learned so far, this 
> might be related to the BootHole bug 
> (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713) that was 
> fixed some time ago.
>
> My generated key is:
>
> root@T495:~/mok# openssl x509 -in MOK.pem -text -noout
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number:
>             42:61:86:b2:29:3d:ca:eb:98:87:ae:3d:74:95:c7:f2:63:8f:8a:3b
>         Signature Algorithm: sha256WithRSAEncryption
>         Issuer: C = PL, ST = Poznan, L = Poznan, O = none, CN = Secure Boot 
> Signing, emailAddress = example@example.com
>         Validity
>             Not Before: Feb 18 19:28:16 2020 GMT
>             Not After : Jan 25 19:28:16 2120 GMT
>         Subject: C = PL, ST = Poznan, L = Poznan, O = none, CN = Secure Boot 
> Signing, emailAddress = example@example.com
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>                 Public-Key: (2048 bit)
>                 Modulus: [cut]
>                 Exponent: 65537 (0x10001)
>         X509v3 extensions:
>             X509v3 Subject Key Identifier:
>                 EC:57:4E:BD:DC:1A:CF:B4:55:16:4A:CE:CB:E4:9E:44:5C:C4:63:F6
>             X509v3 Authority Key Identifier:
>                 EC:57:4E:BD:DC:1A:CF:B4:55:16:4A:CE:CB:E4:9E:44:5C:C4:63:F6
>             X509v3 Basic Constraints: critical
>                 CA:FALSE
>             X509v3 Extended Key Usage:
>                 Code Signing, 1.3.6.1.4.1.311.10.3.6, 1.3.6.1.4.1.2312.16.1.2

This is bad... certs that have 1.3.6.1.4.1.2312.16.1.2 cannot be used
to sign kernels.

Your cert must _not_ have 1.3.6.1.4.1.2312.16.1.2 EKU set on it.

You cannot use the same certificate to sign both kernel and modules.

>             Netscape Comment:
>                 OpenSSL Generated Certificate
>     Signature Algorithm: sha256WithRSAEncryption
>     Signature Value: [cut]
>
> On Tue, May 10, 2022 at 3:26 PM Dimitri John Ledkov 
> <dimitri.ledkov@canonical.com> wrote:
>>
>> the MOK key as generated by Ubuntu/Debian tooling, creates a signing
>> certificate that self-limits itself to only support Kernel Module
>> signing.
>> Signatures made by such certificate, are not trusted by shim for the
>> purpose of code signing of bootloaders (i.e. grub) or kernels (i.e.
>> linux).
>> I also responded this on stackoverflow.
>>
>> The automatically generated MOK key is only usable to sign kernel
>> modules, i.e. self-built DKMS modules.
>>
>> --
>> okurrr,
>>
>> Dimitri
>>
>> On Tue, 10 May 2022 at 11:33, Łukasz Piątkowski <piontec@gmail.com> wrote:
>> >
>> > Hi everyone - I'm new here!
>> >
>> > Sorry for going with my problem directly to the grub-devel maling list, 
>> > but I'm pretty sure my problem is GRUB related. Still, I've spent some 
>> > hours trying to find a solution on the Internet and I failed :( So, here 
>> > it comes - if anyone has time to explain my problem to a layman, it would 
>> > be awesome. Even better, if you can maybe answer here on stackoverflow, 
>> > where it can be easier to find, I believe 
>> > (https://unix.stackexchange.com/questions/701612/cant-load-self-signed-kernel-with-secure-boot-on-bad-shim-signature).
>> >
>> > I'm running ubuntu with Secure Boot on. Everything works fine when I use a 
>> > kernel that comes packaged from cannonical. Still, I have issues running a 
>> > self-signed kernel (this is actually an externally built kernel, that I 
>> > have verified and want to use for my own machine). I'm pretty sure my 
>> > signature with MOK key is OK (verification below), but still when I try to 
>> > boot the kernel from grub, after selecting the correct entry, I get an 
>> > error that reads "Loading ... error: bad shim signature." I'm wrapping my 
>> > head around it and can't find a solution. Why, even though both kernels 
>> > are signed with MOK keys, one of them works and the other doesn't?
>> >
>> > Here's info about kernel signatures:
>> >
>> > root@T495:~# sbsign --key /var/lib/shim-signed/mok/MOK.priv --cert 
>> > /var/lib/shim-signed/mok/MOK.pem /boot/vmlinuz
>> > Image was already signed; adding additional signature
>> >
>> > root@T495:~# sbverify --list /boot/vmlinuz
>> > signature 1
>> > image signature issuers:
>> >  - /C=PL/ST=Poznan/L=Poznan/O=none/CN=Secure Boot 
>> > Signing/emailAddress=example@example.com
>> > image signature certificates:
>> >  - subject: /C=PL/ST=yes/L=yes/O=none/CN=Secure Boot 
>> > Signing/emailAddress=example@example.com
>> >    issuer:  /C=PL/ST=yes/L=yes/O=none/CN=Secure Boot 
>> > Signing/emailAddress=example@example.com
>> > signature 2
>> > image signature issuers:
>> >  - /CN=ubuntu Secure Boot Module Signature key
>> > image signature certificates:
>> >  - subject: /CN=ubuntu Secure Boot Module Signature key
>> >    issuer:  /CN=ubuntu Secure Boot Module Signature key
>> >
>> >
>> > And here about MOK keys:
>> >
>> > root@T495:~# openssl x509 -in /var/lib/shim-signed/mok/MOK.pem 
>> > -fingerprint -noout
>> > SHA1 
>> > Fingerprint=81:A2:93:CB:06:6F:52:BA:D9:E2:39:68:9D:FA:E2:2B:0C:95:3C:F7
>> > root@T495:~# mokutil --list-enrolled | grep "81:a2:93"
>> > SHA1 Fingerprint: 
>> > 81:a2:93:cb:06:6f:52:ba:d9:e2:39:68:9d:fa:e2:2b:0c:95:3c:f7
>> >
>> > If there are any docs that help understand that, I'm happy to be 
>> > redirected there :)
>> >
>> > piontec
>> > _______________________________________________
>> > Grub-devel mailing list
>> > Grub-devel@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]