linux-kernel - Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

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-next>] [day] [month] [year] [list]

Message-ID: <20150825193408.GR8051@wotan.suse.de>
Date:	Tue, 25 Aug 2015 21:34:08 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Liam Girdwood <liam.r.girdwood@...el.com>,
	"Jie, Yang" <yang.jie@...el.com>, joonas.lahtinen@...ux.intel.com
Cc:	Takashi Iwai <tiwai@...e.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Tom Gundersen <teg@...m.no>, Ming Lei <ming.lei@...onical.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kay Sievers <kay@...y.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>, mcgrof@...not-panic.com,
	linux-kernel@...r.kernel.org
Subject: Re: Problems loading firmware using built-in drivers with kernels
 that use initramfs.

On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote:
> Luis, did you tell me the other day that you made the kernel get firmware
> directly from the file system? This regression would be yours then?

I didn't implement that, Linus did in 2012 (see commit abb139e75c2c titled
"firmware: teach the kernel to load firmware files directly from the
filesystem"). But we used to fallback to a userspace helper when the fw was
not present and then Takashi made this optional via commit 7b1269f778782d
titled "firmware: Make user-mode helper optional". Takashi noted in the
Kconfig "The user-mode helper is no longer required unless you have a
special firmware file that resides in a non-standard path". It was not
clarified why that's true though, or what you'd need to do to ensure
that the fw would be available. It would be good for us to elaborate
on that.

More on this below.

> I can also take a look next week when I'm home from vacation.

No worries, I'll look at it.

> From:Liam Girdwood <liam.r.girdwood@...el.com>
> Sent:Tue, 25 Aug 2015 09:05:00 +0100
> To:"Jie, Yang" <yang.jie@...el.com>,dwmw2@...radead.org,"joonas.lahtinen	" <joonas.lahtinen@...ux.intel.com>
> Subject:Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
> 
> >On Mon, 2015-08-24 at 21:50 +0100, Liam Girdwood wrote:
> >> Currently firmware loading with built-in drivers is failing on systems
> >> that mount an initramfs before the root FS is mounted (that contains the
> >> firmware file). Modular drivers work fine.
> >> 
> >> Keyon (Jie, Yang) has done some testing with the Intel audio DSP driver
> >> and found that the built-in firmware loading only works if the firmware
> >> is included as part of the initramfs.

Note that works.

> >> The same has been seen with other
> >> Intel drivers that use firmware.
> >> 
> >> In this case it looks like userspace (udevd ?) is checking initramfs for
> >> pending firmware requests and returning not found if it cant find the
> >> files, but it's not re-checking for any pending firmware requests once
> >> the real FS is mounted. Is it possible to have udevd re-check the
> >> pending firmware requests after the real FS is mounted ?

We are phasing out CONFIG_FW_LOADER_USER_HELPER support in the kernel, support
for udev helper firmware loading was removed from systemd, the only requirement
for it now is the dell rbu driver.

Without CONFIG_FW_LOADER_USER_HELPER it its up to userspace or system
integrators to do the right thing and you have a few options if you are
enabling drivers as built-in:

  * stuff firmware in initramfs
  * built firmware into the kernel

We don't do anything special for pivot_root for built-in, I am not sure if
we should, I don't think we should... can you not do any of the above
two options?

Since folks can stuff firmware into initramfs and that's outside the scope of
how we build the kernel we can't always ensure folks will do one of the above
two options at build time for built-in drivers. If we don't want to do
something for pivot_root the only thing I think we can do is document the
expecations clearly, unless there are other ideas of course.

  Luis
--
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/