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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 19 Sep 2014 14:42:57 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Roman Pen <r.peniaev@...il.com>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [v4 PATCH 1/1] init: fix race between rootfs mount and firmware
 loading

On Fri, Sep 19, 2014 at 09:44:24PM +0900, Roman Pen wrote:
> The thing is that built-in modules are being inited before
> rootfs mount.  Some of the modules can request firmware loading
> from another thread using async 'request_firmware_nowait' call
> on inition, so we can catch this kind of race:
>    rootfs does not exist yet, but we are going to open and load
>    firmware file requesting it from the kernel thread.
> 
> Solution is simple: before any rootfs access firmware loader
> must wait for rootfs mount.

Even simpler solution, don't do that :)

If your hardware needs firmware this early, and you don't put the
firmare into the initrd/initramfs, then it will just be loaded later on,
when the root filesystem is needed and the driver asks for it again
(your driver is failing "nicely" and allows the firmware to be loaded
later, right?  If not, that should be fixed...)

Or, build the firmware into the kernel, I think we still have that
option for some drivers that really wanted/needed this.

What has changed recently that requires this type of patch?  What is
wrong with the above solutions?

thanks,

greg k-h
--
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/

Powered by blists - more mailing lists