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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 27 Jun 2017 12:52:39 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Ming Lei <ming.lei@...hat.com>, yi1.li@...ux.intel.com,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>, nbroeking@...com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        mfuzzey@...keon.com, ebiederm@...ssion.com,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Daniel Wagner <wagi@...om.org>,
        David Woodhouse <dwmw2@...radead.org>,
        jewalt@...innovations.com, rafal@...ecki.pl,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, atull@...nel.org,
        Moritz Fischer <moritz.fischer@...us.com>, pmladek@...e.com,
        Johannes Berg <johannes.berg@...el.com>,
        emmanuel.grumbach@...el.com,
        Luca Coelho <luciano.coelho@...el.com>, luto@...nel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        David Howells <dhowells@...hat.com>, pjones@...hat.com,
        Hans de Goede <hdegoede@...hat.com>, alan@...ux.intel.com,
        Theodore Ts'o <tytso@....edu>, paul.gortmaker@...driver.com,
        mtosatti@...hat.com, mawilcox@...rosoft.com,
        Stephen Boyd <stephen.boyd@...aro.org>,
        Vikram Mulukutla <markivx@...eaurora.org>,
        lkml <linux-kernel@...r.kernel.org>, oss-drivers@...ronome.com
Subject: Re: [PATCH] firmware: wake all waiters

On Tue 27 Jun 12:08 PDT 2017, Luis R. Rodriguez wrote:

> On Tue, Jun 27, 2017 at 11:59:15AM -0700, Bjorn Andersson wrote:
> > On Tue 27 Jun 11:03 PDT 2017, Luis R. Rodriguez wrote:
> > [..]
> > > Let's consider a crazy case where the uevent gets triggered, and userspace goes
> > > and signals Elon Musk somehow to transmit the needed firmware from Mars through
> > > a serial satellite link to earth, and somehow someday the device is finally
> > > ready to upload firmware from userspace. Once Elon's firmware lands home, we
> > > know all needed firmware has arrived so anything missing we can acknowledge now
> > > as missing, so we upload what we can and kick firmward into final-mode to tell
> > > the kernel we know we're really ready and any pending things will have to be
> > > given up.
> > > 
> > > This would prove the custom fallback crap was also never needed.
> > > 
> > 
> > Are you saying that each kernel driver should be written so that it will
> > either do direct loading or use firmwared?
> 
> Hell No! You can fork firmwared or use whatever the hell bin-foo you want.
> Even if its proprietary and glued with evil rainbow unicorns on it.  The dual
> mode, best-effort mode and final-mode devices it implemented are key to what
> you want to mimic as an example to achieve the goal in question.
> 

I'm sorry but your language is totally inappropriate and the reason why
I tend to stay away from firmware-related discussions.

> Please give that thought / architecture solution a spin and let me know if
> it suffices for your needs.
> 

Which solution do you refer to here?

But as I said, in my view, the decision of making the kernel depend on a
user space firmware loading mechanism or direct loading should be that
of the system designer - not the kernel.

Regards,
Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ