Re: [PATCH 4/8] MODSIGN: Provide a utility to append a PKCS#7 signature to a module [ver #4]

[David Howells]

Andy Lutomirski <luto@xxxxxxxxxx> 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.

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

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

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/