Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751285Ab2KFKEl (ORCPT ); Tue, 6 Nov 2012 05:04:41 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:60681 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751042Ab2KFKEi (ORCPT ); Tue, 6 Nov 2012 05:04:38 -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:04:36 +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: 2420 Lines: 62 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. > 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 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. Some application might need the firmware add/remove event. Some may not store the firmware in fs. So now it is difficult to say we can remove firmware loading from user space. Better to just keep it. > 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. 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/