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: <CACVXFVOOEf=Ype=2OGjjjgXZWo=5xd8Hhu2CSTaKTtGAybaA=w@mail.gmail.com>
Date:	Tue, 6 Nov 2012 18:04:36 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Takashi Iwai <tiwai@...e.de>
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

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.

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/