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: <20160903174939.GB32345@dtor-ws>
Date:   Sat, 3 Sep 2016 10:49:39 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        cocci@...teme.lip6.fr, Jacek Anaszewski <j.anaszewski@...sung.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Christian Lamparter <chunkeey@...glemail.com>,
        Julia Lawall <Julia.Lawall@...6.fr>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Andy Lutomirski <luto@...capital.net>,
        Richard Purdie <rpurdie@...ys.net>,
        Wu Fengguang <fengguang.wu@...el.com>,
        Johannes Berg <johannes@...solutions.net>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Michal Marek <mmarek@...e.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Mark Brown <broonie@...nel.org>, Jiri Slaby <jslaby@...e.com>,
        Ming Lei <ming.lei@...onical.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Kevin Cernekee <cernekee@...il.com>,
        Jeff Mahoney <jeffm@...e.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Jonathan Corbet <corbet@....net>, Felix Fietkau <nbd@....name>,
        David Howells <dhowells@...hat.com>,
        Vikram Mulukutla <markivx@...eaurora.org>,
        Alessandro Rubini <rubini@...dd.com>,
        Tom Gundersen <teg@...m.no>, Kees Cook <keescook@...omium.org>,
        Takashi Iwai <tiwai@...e.de>, Gilles.Muller@...6.fr,
        linux-serial <linux-serial@...r.kernel.org>,
        Roman Pen <r.peniaev@...il.com>, Kay Sievers <kay@...y.org>,
        Stephen Boyd <stephen.boyd@...aro.org>, nicolas.palix@...g.fr,
        "Abhay_Salunke@...l.com" <Abhay_Salunke@...l.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thierry Martinez <martinez@...p.org>,
        Josh Boyer <jwboyer@...oraproject.org>
Subject: Re: [RFC] fs: add userspace critical mounts event support

On Fri, Sep 02, 2016 at 09:41:18PM -0700, Linus Torvalds wrote:
> On Sep 2, 2016 9:20 PM, "Dmitry Torokhov" <dmitry.torokhov@...il.com> wrote:
> >
> > Like what? Some devices do need to have firmware loaded so we know
> > their capabilities, so we really can't push the firmware loading into
> > "open".
> 
> So you
> (a) document that

Document that device may come up half-broken? Not sure how that would
help end user.

> (b) make the driver only build as a module

Unfortunately module loading and availability of firmware is very
loosely coupled. Of course, if you only load modules from the same
partition that your firmware is on you can get away with it, but if some
of the modules are in initramfs and firmware is on final root fs then
it still does not work. And populating also initramfs with firmware that
might be used once in a 1000 boots is somewhat wasteful. That is not
talking about systems that do not wish to use modules for one reason or
another, or even more esoteric setups where non-essential for boot
firmware can be mounted later over nfs, etc, etc.

> (c) make sure the module and the firmware go together

I do not think it is always possible. Quite often it is though, at the
expense of increasing kernel/initramfs size.

> 
> End of problem.
> 
> Why make up random interfaces for crazy stuff?

Because we want a solution that works well for all cases, simple and
complex. This includes allowing drivers to be built into the kernel but
allow them waiting for additional data (config/firmware) that may become
available later in the game. We just need to be able to tell them when
it does not make sense to wait anymore as the data they want is not
coming, and do it more reliably then simply declaring 10 or 30 or 300
seconds time out.

Thanks.

-- 
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ