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. > > 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-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
