From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754124AbbETQAa (ORCPT ); Wed, 20 May 2015 12:00:30 -0400 Received: from mail-la0-f45.google.com ([209.85.215.45]:36789 "EHLO mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752344AbbETQA1 (ORCPT ); Wed, 20 May 2015 12:00:27 -0400 MIME-Version: 1.0 In-Reply-To: <31479.1432127671@warthog.procyon.org.uk> References: <20150515123513.16723.96340.stgit@warthog.procyon.org.uk> <20150515123551.16723.7733.stgit@warthog.procyon.org.uk> <555BDA4B.6020207@kernel.org> <31479.1432127671@warthog.procyon.org.uk> From: Andy Lutomirski Date: Wed, 20 May 2015 09:00:05 -0700 Message-ID: Subject: Re: [PATCH 4/8] MODSIGN: Provide a utility to append a PKCS#7 signature to a module [ver #4] To: David Howells Cc: Andy Lutomirski , Rusty Russell , Michal Marek , Matthew Garrett , keyrings@linux-nfs.org, Dmitry Kasatkin , Luis Rodriguez , "linux-kernel@vger.kernel.org" , Seth Forshee , LSM List , David Woodhouse Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 20, 2015 at 6:14 AM, David Howells wrote: > Andy Lutomirski 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