linux-kernel - Re: [PATCH RFC 0/4] Add firmware signature file check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5h4nl39gt9.wl%tiwai@suse.de>
Date:	Tue, 06 Nov 2012 11:17:06 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, joeyli <jlee@...e.com>,
	Jiri Kosina <jkosina@...e.cz>,
	David Howells <dhowells@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH RFC 0/4] Add firmware signature file check

At Tue, 6 Nov 2012 18:04:36 +0800,
Ming Lei wrote:
> 
> On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai <tiwai@...e.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/