Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933251AbbESPa2 (ORCPT ); Tue, 19 May 2015 11:30:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42545 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932529AbbESPa1 (ORCPT ); Tue, 19 May 2015 11:30:27 -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> To: Andy Lutomirski Cc: dhowells@redhat.com, Andy Lutomirski , Linus Torvalds , Michal Marek , David Woodhouse , Abelardo Ricart III , Linux Kernel Mailing List , Sedat Dilek , keyrings@linux-nfs.org, Rusty Russell , LSM List , Borislav Petkov , Jiri Kosina 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: <1750.1432049417.1@warthog.procyon.org.uk> Date: Tue, 19 May 2015 16:30:17 +0100 Message-ID: <1752.1432049417@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2451 Lines: 66 Andy Lutomirski wrote: > I'll assume that everyone uses a 256-bit hash. UEFI makes it very likely that SHA256 is in use, at least on x86_64. > The public key is tiny, and the signature is 512 bytes per module. > (Actually, it's probably more because of PKCS garbage. 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. We do have to allow people to load external modules. Yes, you could argue that you should just disable all your security systems if you want to do that... > This is a total of ~21kB of non-swappable storage and 2MB of disk space for > all the signatures. Disk space is a lot cheaper than RAM. > Ed25519 Is it endorsed by various governmental authorities? It's not entirely clear. And also the aforementioned authorities may mandate minimum key (eg. 2048) and digest sizes (eg. 256) which we need to deal with. > With the hash-based scheme I outlined, the kernel text needed is > nearly zero. What matters is kernel text *plus* kernel data. > What integrity stuff? IIRC dm-verity doesn't use asymmetric crypto at > all. IMA probably does, though. IMA. > For firmware validation, there's no good reason it couldn't work exactly > like module signatures. That's really impractical. It would mean that the kernel would have to be built with a hash, grand-hash, great-grand-hash or whatever that covers every possible firmware blob you might want to load. If a vendor releases a new firmware blob, this has to be added to the linux-firmware hash list, say, then the hash of that added to the kernel, say, and the kernel rebuilt and reissued before the firmware blob can be used. With a key-based approach, you just need to get a signature for the new firmware blob. You can even sign it yourself and add your key to your UEFI database. > For kexec, I think that the main use is for crash dumps We also want to be able to kexec new kernels on servers to avoid heavy duty hardware reboot cycles. But you can't put the new kernel's hash in the old kernel. 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/