Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751467Ab2KFKRK (ORCPT ); Tue, 6 Nov 2012 05:17:10 -0500 Received: from cantor2.suse.de ([195.135.220.15]:39203 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750988Ab2KFKRH (ORCPT ); Tue, 6 Nov 2012 05:17:07 -0500 Date: Tue, 06 Nov 2012 11:17:06 +0100 Message-ID: From: Takashi Iwai To: Ming Lei 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 Subject: Re: [PATCH RFC 0/4] Add firmware signature file check 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> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3491 Lines: 91 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. > > 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... > Some application > might need the firmware add/remove event. Then this is already broken with the direct fw loading on 3.7, no? > 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. > > 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. Takashi -- 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/