Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751606Ab2KFKlD (ORCPT ); Tue, 6 Nov 2012 05:41:03 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:60158 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751110Ab2KFKk7 (ORCPT ); Tue, 6 Nov 2012 05:40:59 -0500 MIME-Version: 1.0 In-Reply-To: References: <1348152065-31353-1-git-send-email-mjg@redhat.com> <20121029174131.GC7580@srcf.ucam.org> <20121031173728.GA18615@srcf.ucam.org> <1351743715.21227.95.camel@linux-s257.site> <20121101131849.752df6fd@pyramind.ukuu.org.uk> Date: Tue, 6 Nov 2012 18:40:57 +0800 Message-ID: Subject: Re: [PATCH RFC 0/4] Add firmware signature file check From: Ming Lei To: Takashi Iwai Cc: Matthew Garrett , Alan Cox , joeyli , Jiri Kosina , David Howells , Rusty Russell , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4327 Lines: 118 On Tue, Nov 6, 2012 at 6:17 PM, Takashi Iwai wrote: > At Tue, 6 Nov 2012 18:04:36 +0800, > Ming Lei wrote: >> >> On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai wrote: >> > >> > Right, and it's intentionally dropped so. For the non-default fw >> > path, it can be added via proc dynamically or via kconfig statically. >> > If the firmware is generated via udev, then it doesn't make sense to >> > check a static signature file. >> >> kconfig should be better, and proc isn't a good way because it >> is a bit late. Also the firmware might be loaded dynamically from other >> where(network, ...). So it is better to fall back on user space if the >> firmware file isn't found by direct loading even firmware signature >> is enabled. > > It will even with my patch, when enforce_sig is false. It is true if all firmwares are signed on safe boot. If firmware is allowed to be loaded from network or other non-fs place in secure distribution, your patch will break this loading. > >> > A "regression" can't happen in this case because the secure boot is >> > a completely new stuff :) For normal boot, sig_enforce is false, so >> > no behavior change here (well my patch still applies the signature >> > check for direct fw loading, but it won't regress at least). >> >> Got it, so FIRMWARE_SIG and MODULE_SIG should be enabled only >> for secure boot. > > The kernels with these kconfigs set can run on normal systems. In > non-secure boot mode, however, sig_enable option are off, thus the > fallback is still applied. > >> The regression might still be triggered if falling back on user space is not >> supported, see above. >> >> > >> >> Also the default search path in firmware_class.c is from built-in path of >> >> udev, and distributions may customize their firmware path by udev >> >> configure option. >> > >> > Well, the default paths in kernel can be changed to follow that as >> > well, no? >> > >> >> > Honestly speaking, I have a feeling that we should rather go for >> >> > getting rid of udev fw loading. The fw loader code is overly complex >> >> >> >> Yes, I have the feeling too, but we need to make sure no regressions >> >> introduced. >> > >> > Right. And I guess the exceptional firmware case is better found by >> > checking udev. But it's a bit off topic from secure boot. >> >> Not sure, some distributions may not use udev at all. > > Hmm, I can't imagine a system without udev but still supporting the > firmware loading with user-space interaction... It is not so difficult, :-) Some embedded systems use mdev in busybox, and some can just parse the firmware event and run the below script: Documentation/firmware_class/hotplug-script on firmware ADD event. I remembered that android loading is very simple. > >> Some application >> might need the firmware add/remove event. > > Then this is already broken with the direct fw loading on 3.7, no? Maybe, the direct loading hasn't been tested widely, and depends on user space. >> Some may not store the >> firmware in fs. > > And these won't satisfy the firmware signing, so we don't need to care > too much. > >> So now it is difficult to say we can remove firmware loading from user >> space. Better to just keep it. > > Yeah, I don't mean to drop it now. But I meant to go for dropping > it. For example, put a deprecated flag and give a warning for udev fw > loading path so that user notices something to be fixed. Maybe we can do it until direct loading has been tested for some time. > >> > Obviously no distro releases using 3.7-rc since it's still rc. >> > But what's your point? >> >> I mean direct loading hasn't been tested completely, so we don't >> know which distributions may fallback on user space loading. > > The transition to direct fw loading is seamless, so I don't think > you can see which drivers use udev fw loading from the results of > distros... It might reveal some potential issues of direct fw loading > (like udev-trigger dependency), though. The clue can be found from debug message. Thanks, -- Ming Lei -- 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/