Comment # 9 on bug 1209006 from Joey Lee

(In reply to Michal Suchanek from comment #6)
> On Leap we don't need the secondary keyring at all, we have a downstream
> patch that loads the MOK keys into platform keyring, and verifies modules
> with platform keyring.

The CONFIG_INTEGRITY_MACHINE_KEYRING .machine keyring needs .secondary trusted
keyring. 

> 
> In upstream the MOK keys are loaded into machine keyring which then should
> get loaded into secondary keyring.

Looks it's not. 

Base on v6.2 kernel, keys in .machine keyring still must be trusted(signed) by
key in built-in/secondary keyring. It applies restrict_link_to_ima and depends
on CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY.

If the key can not pass the restriction check, kernel will put to key to
.platform keyring. The logic is in add_to_machine_keyring(), but I didn't test
it yet.

So, currently the .machine keyring is NOT useful for loading a MOK-signed
kernel module. I think all MOKs will be loaded to .platform keyring. Unless
Eric Snowberg's MOK CA patch be accepted:

Eric Snowberg <eric.snowberg@oracle.com>
[PATCH v4 0/6] Add CA enforcement keyring restrictions
https://lore.kernel.org/lkml/20230207025958.974056-1-eric.snowberg@oracle.com/
[PATCH v4 6/6] integrity: machine keyring CA configuration

> 
> This option is for loading additional keys (which the name does not reflect)
> in a specific way different from the default (which the name does not
> reflect) and is incompatible with machine keyring (which would have to be
> patched out to enable it).
> 
> Does not seem to work for me, anyway:
> 
> cat /proc/keys | grep machine
> 31db47ec I------     1 perm 1f0b0000     0     0 keyring   .machine: empty

Kernel will check the existence of MokListTrustedRT. So we need to run "mokutil
--trust-mok", otherwise all MOK will go to .platform keyring. But, the above
tracing, unless the MOK be signed by built-in key. Then it still go to
.platform keyring.