Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754810AbbESSqn (ORCPT ); Tue, 19 May 2015 14:46:43 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:33595 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822AbbESSql (ORCPT ); Tue, 19 May 2015 14:46:41 -0400 MIME-Version: 1.0 In-Reply-To: <5261.1432060684@warthog.procyon.org.uk> References: <31154.1431965087@warthog.procyon.org.uk> <555A88FB.7000809@kernel.org> <29742.1432025631@warthog.procyon.org.uk> <1752.1432049417@warthog.procyon.org.uk> <5261.1432060684@warthog.procyon.org.uk> From: Andy Lutomirski Date: Tue, 19 May 2015 11:46:19 -0700 Message-ID: Subject: Re: Should we automatically generate a module signing key at all? To: David Howells Cc: "linux-kernel@vger.kernel.org" , keyrings@linux-nfs.org, LSM List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2530 Lines: 58 On May 19, 2015 11:38 AM, "David Howells" wrote: > > 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. > No, in the hash tree variant, it really is 32 bytes. No one ever needs the full list once the build is done. > > 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. Both Fedora and RHEL seems to be moving toward having fully-supported configurations with immutable root images. Building those images reproducibly would be fantastic. (Of course, if Fedora or RHEL wants to allow support out-of-tree drivers, that's a different story.) --Andy -- 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/