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

[Takashi Iwai <tiwai@suse.de>]

At Tue, 6 Nov 2012 18:40:57 +0800,
Ming Lei wrote:
> 
> On Tue, Nov 6, 2012 at 6:17 PM, Takashi Iwai <tiwai@suse.de> 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@suse.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.
> 
> 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.

Do we already have such a secure mechanism?  How is the security
assured?


> >> > 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.

But I don't think Android devices will run on secure boot :)
That is, the whole signing madness is just for allowing boot on
upcoming machines that need the secure boot mode forced by Microsoft.
And this doesn't match with systems you suggested in the above.

> >> 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.

Yeah, it's a future plan.  But I'd say it's better clarified that we
should go for that direction instead of keeping the stuff forever.


> >> > 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.

Debug messages are turned off on normal machines, unfortunately.


Takashi