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

[Ming Lei]

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