Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 20 May 2015 09:00:05 -0700 | Subject | Re: [PATCH 4/8] MODSIGN: Provide a utility to append a PKCS#7 signature to a module [ver #4] |
| |
On Wed, May 20, 2015 at 6:14 AM, David Howells <dhowells@redhat.com> wrote: > Andy Lutomirski <luto@kernel.org> wrote: > >> > enum pkey_id_type { >> > PKEY_ID_PGP, /* OpenPGP generated key ID */ >> > PKEY_ID_X509, /* X.509 arbitrary subjectKeyIdentifier */ >> > + PKEY_ID_PKCS7, /* Signature in PKCS#7 message */ >> > PKEY_ID_TYPE__LAST >> > }; >> > >> >> I don't understand these comments. "OpenPGP generated key ID" refers to the >> name of a key. "X.509 arbitrary subjectKeyIdentifier" also refers to a name >> of a key. > > OpenPGP was how we did things originally. We then switched to X.509 because > we had to take account of UEFI. These values are implicit parts of the kernel > ABI. > >> "Signature in PKCS#7 message" refers to a signature style. This seems >> inconsistent. > > Not precisely. The format of the descriptor is immutable given the particular > magic number. You set the ID type to that and all the other fields bar one to > zero and you put the signature and all the metadata in the PKCS#7 blob which > you place directly prior to the descriptor (the length of the blob is the one > thing you do need to specify). Effectively, it's an override.
Is there a document anywhere in the kernel tree that defines the actual format? I suspect that this will confuse most people who read the code right now.
> >> Also, I think we're really going to want signatures that specify their >> purpose, e.g. "module named xyz" or "firmware file named abc" or "kexec >> image". Let's get this right the first time rather than needing yet another >> type in the very near future. > > If this is so, then this _must_ also apply to your hash list idea.
Definitely.
> >> Finally, why are we using PKCS#7 for this? Can't everything except kexec >> images use raw signatures in some trivial non-ASN.1-ified format? A raw >> signature can reference a UEFI-sourced key just fine. > > We have PKCS#7 already in the kernel. It's a standard. We can add attributes > of our own devising to extend it if necessary (say your typing idea referenced > above). > >> It could be as simple as: >> >> 4 bytes of signature type >> (length of pubkey identifier, pubkey identifier) >> 4 bytes of purpose >> (length of purpose-specific data, purpose-specific data) > > Let's not create yet another unextendable non-standard standard.
It doesn't really have to be a standard at all.
Actually, I don't see why we are even trying to make the module signature format compatible across kernel versions. The module payload is completely incompatible across kernel versions already. Firmware is a different story, of course.
Also, I'll personally take some simple ad-hoc thing over PKCS#7 any day. I've tried reading the PKCS stuff. 90% is completely inapplicable to anything the kernel (or the Internet in general, for that matter) will ever do, and the other 10% is very poorly designed.
Heck, moving to NaCl format might be a good idea except for the NIST/FIPS compliance part.
--Andy
| |