1. Please describe the problem:

I have secure boot with UEFI set up with a custom PK (owner key), KEK and DB keys. I am able to boot, but any non-fedora module signed with my DB key does not work, in spite of my key being in the kernel's keyring (see log output).

I have worked with this setup since 2016.

2. What is the Version-Release number of the kernel:

uname -r: 5.0.8-200.fc29.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

I first noticed this with the 5.0.8 kernel. It has worked, modulo disabling secure boot during dnf system-upgrade, from fedora whatever version we were on in 2016 (maybe 24?) through to now.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Well, it consistently fails on my platform. I'm going to try booting an older kernel to see if it still works there and I will also try a rawhide kernel.

I have tried re-signing the kernel modules. This does not help, unfortunately.

If it helps I'm running a dell xps 9343 from 2015.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

6. Are you running any modules that not shipped with directly Fedora's kernel?:

Not when this bug happens as they won't load. I'm (by necessity) loading broadcom's wl drivers and building using akmods from rpmfusion. I have no choice here, otherwise I can't use my wireless card.

However, since module verification is failing for all third party modules, my kernel is currently "untainted". Only modules signed by fedora will load.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

rather than upload the whole thing, here are the relevant lines:

[    1.012532] integrity: Loading X.509 certificate: UEFI:db
[    1.014742] integrity: Loaded X.509 cert 'Antony Signing Key 2016: 2d7ed9070075c9c23ef13f176701e68d84d708e7'
[    1.017115] ima: Allocated hash algorithm: sha1

<snip> 

[   11.819432] PKCS#7 signature not signed with a trusted key

The latter dmesg message is produced on any modprobe of kernel modules I signed.

The modules themselves are signed using a key stored on a smartcard. sign-file (provided in the kernel sources) appears to accept whatever those pkcs11 urls are called, so this is the acceptable privkey:

pkcs11:model=CardOS%20V5.0%2c%20201;manufacturer=www.atos.net%2fcardos;serial=020518CF000A3429;token=UEFI;id=%1e%8b%01%0b%d1%a7%ec%5b%df%8b%47%bd%be%9c%6a%da;object=Antony%20Secureboot%20Signing%20Key%202016

While the pubkey is just a path to the certificate. sign-file does not report an error and a looking at the binary kernel objects, they appear signed.

I'm not aware of any tools to validate signed kernel modules (please let me know if there are). As far as I can tell, signing constitutes throwing a pkcs#7 signature on the end of a file - I'm verifying the signatures basically using a hex editor and saying "well, the common name from the cert is there so it's probably ok".

Further,

efi-readvar -v PK                                                                                                           1 
Variable PK, length 883
PK: List 0, type X509
    Signature 0, size 855, owner 8a4d80e9-1fff-490a-9537-7725ea401f77
        Subject:
            CN=Antony Platform Key 2016
        Issuer:
            CN=Antony Platform Key 2016

efi-readvar -v KEK
Variable KEK, length 865
KEK: List 0, type X509
    Signature 0, size 837, owner 8a4d80e9-1fff-490a-9537-7725ea401f77
        Subject:
            CN=Antony KEK 2016
        Issuer:
            CN=Antony KEK 2016

efi-readvar -v db 
Variable db, length 903
db: List 0, type X509
    Signature 0, size 875, owner 8a4d80e9-1fff-490a-9537-7725ea401f77
        Subject:
            CN=Antony Secureboot Signing Key 2016
        Issuer:
            CN=Antony Secureboot Signing Key 2016

cat /proc/keys | grep Antony
19f3b28a I------     1 perm 1f010000     0     0 asymmetri Antony Secureboot Signing Key 2016: 2d7ed9070075c9c23ef13f176701e68d84d708e7: X509.rsa 84d708e7

Openssl -in /path/to/cert -text -noout:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d3:7a:01:0f:1d:31:ab:20
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Antony Secureboot Signing Key 2016
        Validity
            Not Before: Oct 25 21:31:31 2016 GMT
            Not After : Oct 19 21:31:31 2041 GMT
        Subject: CN = Antony Secureboot Signing Key 2016
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)

both KEK and PK also use sha256WithRSAEncryption, so I'm at a loss to explain the ima sha1 loaded statement in dmesg. In fairness, a previous kernel log I picked at random (5.0.5) also has this statement.

To be clear, I haven't rebuilt the shim. To keep things relatively simple, I signed the shim with my secureboot keys (currently on the affected machine, booted uefi secure boot) but let the shim use fedora's trusted keys to load the kernel and its own modules. I could custom-sign the lot I guess, but for the moment I am (was) happy with this setup.

If running a custom platform key in uefi secure boot is not supported, then it should be, because this is literally the whole point of secure boot.