0

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. 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?

Verification:

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/[email protected]
image signature certificates:
 - subject: /C=PL/ST=yes/L=yes/O=none/CN=Secure Boot Signing/[email protected]
   issuer:  /C=PL/ST=yes/L=yes/O=none/CN=Secure Boot Signing/[email protected]
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

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

I have no idea what is going on :|

2
  • It sounds like you have removed the shim's certificate from the UEFI db storage. Run mokutil --db should show you a list of carious certs, of which Ubuntu's shim cert and your own cert have to be loaded, one for the shim, the other for the kernel. Commented May 6, 2022 at 18:25
  • I don't think so. As far as I understand, shim is signed with Microsoft's keys and only they need to be in DB. Once shim is running, it has its own key DB and my key is enrolled there. I have just checked, and in 'db' there are only MS' and Lenovo's keys, but not Canonical's - still their kerne; boots fine.
    – piontec
    Commented May 7, 2022 at 19:32

1 Answer 1

1

MOK.pem is generated on Ubuntu/Debian systems with extended usage attributes set to support kernel module signing only. That certificate is not usable to sign UEFI bootloaders or kernels as needed to pass verification by shim.

In shim source code you can see that:

   #define OID_EKU_MODSIGN "1.3.6.1.4.1.2312.16.1.2"

   static BOOLEAN verify_eku(UINT8 *Cert, UINTN CertSize)
   {
    ...
    x509 = d2i_X509 (NULL, &Temp, (long) CertSize);
    if (x509 != NULL) {
        eku = X509_get_ext_d2i(x509, NID_ext_key_usage, NULL, NULL);
        if (eku) {
        ...
                if (OBJ_cmp(module_signing, key_usage) == 0)
                    return FALSE;
        ...
            }
        }
        return TRUE;
}

Meaning if module_signing extended key usage is set, the signing cert is not considered valid by shim for the purposes of validating grub or linux kernel binaries.

Create your own secureboot signing certificate without such an EKU, enroll it into either mok or db, and use it for signing.

Ref: https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/KeyGeneration

Ref: https://github.com/rhboot/shim/blob/main/shim.c#L106

1
  • Yes, so the root cause was my signing key having '1.3.6.1.4.1.2312.16.1.2' key usage. Thanks for pointing this out!
    – piontec
    Commented May 11, 2022 at 10:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .