kernel signed by mok failed to boot if secure boot is on

[Yuan-Chen Cheng]

On Focal, create a mok and enroll it, use it to sign test kernel as the secure boot is on.

# sh -x test.sh
+ sbverify --cert TestKer.pem /boot/vmlinuz-5.13.0-9010-oem
Signature verification OK
+ openssl x509 -in TestKer.pem -outform der -out TestKernel.der
+ mokutil --test-key TestKernel.der
TestKernel.der is already enrolled

As the secure boot is on, can't load above kernel.

The error message is:

/boot/vmlinuz-5.13.0-9010-oem has invalid signature.

Machine: Latitude 7520
bios: 1.6.0
shim-signed: 1.40.6+15.4-0ubuntu7
grub-efi-amd64-signed: 1.167.2+2.04-1ubuntu44.2

[Yuan-Chen Cheng (ycheng-twn)]

downgrade shim-signed to 1.40.4+15+1552672080.a4a1fbe-0ubuntu2 and
shim 15+1552672080.a4a1fbe-0ubuntu2

Then I can't reproduce this issue.

[Kai-Chuan Hsieh (kchsieh)]

@ycheng-twn

I try to update my manifest to fossa-davos-adl X142 and install iso on DLPN-MT-EVT-C1/BIOS 0.10.28.
I can finish the installation and the secure boot is enabled after installation.

[Ivan Hu (ivan.hu)]

@ycheng-twn

Have you also updated the Grub2?

[Yuan-Chen Cheng (ycheng-twn)]

as this is reproduced, grub version

# dpkg -l |grep grub
ii grub-common 2.04-1ubuntu26.12 amd64 GRand Unified Bootloader (common files)
ii grub-efi-amd64 2.04-1ubuntu44.2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii grub-efi-amd64-bin 2.04-1ubuntu44.2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version, signed)
ii grub2-common 2.04-1ubuntu26.12 amd64 GRand Unified Bootloader (common files for version 2)

[Yuan-Chen Cheng (ycheng-twn)]

note upgrade the follow pkg

shim-signed: 1.40.7+15.4-0ubuntu9
grub-common 2.04-1ubuntu26.13
grub2-common 2.04-1ubuntu26.13

from the proposed channel does not help.

[Ivan Hu (ivan.hu)]

Manually test with my UEFI develop kit(RainbowPass) platform by following procedures and cannot reproduce this issue.

1. install focal
2. update shim-signed to 1.40.6+15.4.0ubuntu7 and grub2 to 2.04-1ubuntu26.12
3. install mainline kernel(unsigned), https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8.18/
4. check or create test kernel key
   * mkdir -p /var/lib/test_ker/
   * openssl genrsa -out /var/lib/test_ker/TestKer.priv 2048
   * openssl req -new -x509 -sha256 -subj '/CN=TestKer-key' -key /var/lib/test_ker/TestKer.priv -out /var/lib/test_ker/TestKer.pem
   * openssl x509 -in /var/lib/test_ker/TestKer.pem -inform PEM -out /var/lib/test_ker/TestKer.der -outform DER
5. signed kernel
  * sbsign --key /var/lib/test_ker/TestKer.priv --cert /var/lib/test_ker/TestKer.pem --output vmlinuz-5.8.18-05.0818-generic.signed vmlinuz-5.8.18-05.0818-generic
6. enroll mok key
 * mokutil --import Testker.der
7. reboot

[Yuan-Chen Cheng (ycheng-twn)]

Could you also enrolled mok for kernel module?
(One mok for kernel and the other for kernel module)

It seem two mok will confuse shim.

[Ivan Hu (ivan.hu)]

After singing kernel modules and enroll key to MOK, still cannot reproduce this with my UEFI develop kit(RainbowPass) platform.

[Ivan Hu (ivan.hu)]

Test again with my UEFI develop kit(RainbowPass) platform by following procedures and still cannot reproduce this issue.

1. install focal
2. update shim-signed to 1.40.6+15.4.0ubuntu7 and grub2 to 2.04-1ubuntu26.12
3. install mainline kernel(unsigned), https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8.18/
4. signed kernel module and enrolled key to MOK( install a DKMS and followed the official procedures)
5. run the script and EFI application to signed key and enroll key to MOK(need to disable secureboot first), https://github.com/Ivanhu5866/MokEnrollKey/blob/master/mok_testkernel_key.sh
this basically is the same procedure as OEM image installation.
6. reboot

@YC
per talk, please enable the shim log for me to check first by
$sudo mokutil --set-verbosity true

[Yuan-Chen Cheng (ycheng-twn)]

AI: the message scroll up, so let me pass the machine to Ivan.

[Ivan Hu (ivan.hu)]

Got the Latitude 7520 machine, from the shim's log, it seems something wrong in the self signed certificate and the binary is not authorized.

And do some tests, basically base on the comment#6, install another test kernel and signed/enrolled with another MOK key manually.

1. install test kernel(unsigned), v5.14.0-rc7
2. shim and grub have already been updated.
3. create a MOK key
   * mkdir -p /var/lib/test_ker/
   * openssl genrsa -out /var/lib/test_ker/TestKer.priv 2048
   * openssl req -new -x509 -sha256 -subj '/CN=TestKer-key' -key /var/lib/test_ker/TestKer.priv -out /var/lib/test_ker/TestKer.pem
   * openssl x509 -in /var/lib/test_ker/TestKer.pem -inform PEM -out /var/lib/test_ker/TestKer.der -outform DER
4. signed kernel
  * sbsign --key /var/lib/test_ker/TestKer.priv --cert /var/lib/test_ker/TestKer.pem --output vmlinuz-5.14.0-051400rc7-generic.signed vmlinuz-5.14.0-051400rc7-generic
6. enroll mok key
 * mokutil --import Testker.der
7. reboot

The test kernel 5.14 and MOK key work normally.

[Steve Langasek (vorlon)]

The original bug report does not say how the MOK has been generated.

If it is generated using the maintainer script integrations in shim-signed (the update-secureboot-policy command), note that the openssl config in /usr/lib/shim/mok/openssl.cnf generates a key which is specifically annotated as only being allowed for signing modules, NOT kernels. It is invalid to use this dkms key for signing kernels, you would need to generate another key (as shown in various comments in this bug report) that does not have the EKU set to say it's only for modules.

It is possible that an earlier version of shim was not enforcing this constraint and that's why it worked for you before upgrade.

[Jacob (jacob11)]

Hi Steve Langasek,
If an attacker is able to sign a custom kernel module & compromise a system via that means is there a reason to restrict the rather easy to use `update-secureboot-policy --new-key` method to only kernel modules? (Can we modify it to allow signing kernels in addition to kernel modules?)

[Steve Langasek (vorlon)]

A signed kernel module and a signed kernel have different security properties: a signed kernel has access to the firmware state prior to calling ExitBootServices, a module does not. So, no, this implementation in the shim package which was implemented specifically to support dkms modules should not be changed to support signing kernels.

[Jacob (jacob11)]

Hi Steve Langasek,
Could we add an option to `update-secureboot-policy` so that it can generate a key that works for signing modules & kernels ?

As an aside, if an attacker has compromised a system and they generate a signing key ... they could modify and attempt to enrol a key that allows kernel signing ...

[Ivan Hu (ivan.hu)]

Follow up the tests for comment#12,

the same test kernel v5.14.0-rc7 signed with the original created key in /var/lib/shim-signed/test_kernel will not boot up with getting the invalid signature error.

compare the keys between /var/lib/shim-signed/test_kernel and comment#12(/var/lib/test_ker/), the fail one(in /var/lib/shim-signed/test_kernel) has the (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID.

It seems it is because using the "Module-signing only" (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID to sign the test kernel that cause signature verify failed.

@YC
I know the OEM projects base on the my EFI applicaiton and script to generate/enroll MOK keys for test kernels, https://github.com/Ivanhu5866/MokEnrollKey/blob/master/mok_testkernel_key.sh
Could you provide the exact script how the MOK has been generated/enrolled and maybe openssl.cnf for checking?

[Yuan-Chen Cheng (ycheng-twn)]

Hi Ivan, per check, I do add "-config /usr/lib/shim/mok/openssl.cnf" as create mok for kernel in development mode. I'll re-create a key and update test result.

[Yuan-Chen Cheng (ycheng-twn)]

It test pass on UMA machine. I heard there is failed case on I+N, will also test on that.

[Steve Langasek (vorlon)]

On Sun, Aug 29, 2021 at 09:02:38PM -0000, Jacob wrote:

> Could we add an option to `update-secureboot-policy` so that it can
> generate a key that works for signing modules & kernels ?

This would be a low priority to change, and we would need to take a good
deal of care around the user interface and documentation for this because we
do not want to be giving users a gun to point at their feet.

The only reason to add a key to MOK that can be used for signing kernels is
if you're not using an official Ubuntu kernel. I think the documentation
for how to generate keys for this belongs with instructions around booting
unofficial kernels; and wherever that gets documented, it can just as well
lay out the full openssl invocation instead of pointing to
update-secureboot-policy. And NOT putting it in update-secureboot-policy
makes it less likely that users are going to cargo-cult a one-liner command
without context.

> As an aside, if an attacker has compromised a system and they generate a
> signing key ... they could modify and attempt to enrol a key that allows
> kernel signing ...

The "attempt to enroll" requires the user to interface with MokManager at
the console. It is by design that you cannot non-interactively enroll a MOK
from userspace. So this scenario is already accounted for and still
prevents an attacker from getting persistent access to the firmware without
involvement of someone with control of the local console.

[Yuan-Chen Cheng (ycheng-twn)]

per my current test on i+n, it works fine.

There seems to have some other single failure case, still wait the machine to be availe.

Give so, close it here for now.

[Yuan-Chen Cheng (ycheng-twn)]

got the other single failure case and confirm it's caused by another mistake.