Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751561AbbESSiM (ORCPT ); Tue, 19 May 2015 14:38:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57710 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbbESSiJ (ORCPT ); Tue, 19 May 2015 14:38:09 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <31154.1431965087@warthog.procyon.org.uk> <555A88FB.7000809@kernel.org> <29742.1432025631@warthog.procyon.org.uk> <1752.1432049417@warthog.procyon.org.uk> To: Andy Lutomirski Cc: dhowells@redhat.com, "linux-kernel@vger.kernel.org" , LSM List , keyrings@linux-nfs.org Subject: Re: Should we automatically generate a module signing key at all? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5260.1432060684.1@warthog.procyon.org.uk> Date: Tue, 19 May 2015 19:38:04 +0100 Message-ID: <5261.1432060684@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2421 Lines: 56 Andy Lutomirski wrote: > > There is metadata selecting the particular key to be checked against, so > > with a 512-byte signature, you get around 500 bytes of metadata and ASN.1 > > wrappings. We could probably trim that some more by removing PKCS#7 > > attribute sections. > > You could trim even more by simply not using PKCS#7. A raw PKCS#1 > signature would be just fine. (We should really be using PSS, > though.) Trimming the attributes reduces it to about 150 bytes over the signature. PKCS#7 is handy because it's a standard that has standard ways of specifying digest and crypto algorithms and key lookups. Plus we need it available to verify PE-signed kernel images. > ...and for users who need to comply with unfortunate standards, If you want to get into certain markets, you have to care. > The kernel data involved is 32 bytes. No, it isn't. It's the entire hash list and whatever metadata it requires. Dynamically loaded kernel data is *still* kernel data. > I don't think that the needs of IMA users should affect normal people > who run 'make' on their kernel tree. The sad fact is that 'normal' Linux users use distribution kernels and don't give two figs about how it does what it does (or use something like Android and don't even realise Linux exists). I'm not that sure people who build their own kernels can really said to be 'normal' in this sense. > Deterministic builds can't apply to firmware regardless, so users are > trusting a vendor one way or another. And for Chromebook or > Atomic-like uses, hashes are fine. That may be so, but that doesn't help Fedora, RHEL and suchlike that run on less restricted hardware. For an embedded platform, a monolithic kernel may also be fine. > Agreed, although I don't understand why UEFI is a reasonable place for > firmware or module keys. UEFI is a giant implementation detail, > whereas module and firmware validation is really a cross-architecture > thing. Because it exists and we have to use it on many new machines, so we might as well make best use of it if it's there. Besides, if M$ have their way, it'll be everywhere - even on your toaster;-) David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/