On Fri, 13 Sept 2024 at 11:32, David Howells <dhowells@xxxxxxxxxx> wrote: > > Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > > Personally I don't think the argument above holds water. With > > IPsec we had a similar issue of authenticating untrusted peers > > using public key cryptography. In that case we successfully > > delegated the task to user-space and it is still how it works > > to this day. This is slightly disingenuous. The kernel itself has no need to trust the peer - it only manages the network pipe and authenticates/decrypts the packets on behalf of user space. The situation would be radically different if the kernel itself would communicate over IPsec (or HTTPS) directly. Likewise for module loading: there is no way the authentication can be delegated to user space, unless that user space component is authenticated by the kernel (and runs in a special, hardened context). > > It transpires that we do actually need at least a PGP parser in the kernel - > and it needs to be used prior to loading any modules: some Lenovo Thinkpads, > at least, may have EFI variables holding a list of keys in PGP form, not X.509 > form. > > For example, in dmesg, you might see: > > May 16 04:01:01 localhost kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table) > May 16 04:01:01 localhost kernel: integrity: Problem loading X.509 certificate -126 > MokListRT is a shim construct, which is a component in the downstream distro boot chain. It is not part of EFI, and in your case, this is unlikely to be specific to Lenovo systems. > On my laptop, if I dump this variable: > > efivar -e /tmp/q --name=605dab50-e046-4300-abb6-3dd810dd8b23-MokListRT > > And then looking at the data exported: > > file /tmp/q > > I see: > > /tmp/q: PGP Secret Sub-key - > > The kernel doesn't currently have a PGP parser. I've checked and the value > doesn't parse as ASN.1: > > openssl asn1parse -in /tmp/q -inform DER > 0:d=0 hl=2 l= 21 prim: cont [ 23 ] > Error in encoding > 001EBA93B67F0000:error:0680007B:asn1 encoding routines:ASN1_get_object:header too long:crypto/asn1/asn1_lib.c:105: > > which would suggest that it isn't X.509. > This should be fixed in shim not the kernel.
