linux-kernel - Re: [PATCH v9 1/5] firmware: add extensible driver data params

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Jun 2017 10:26:21 +0900
From:   AKASHI Takahiro <takahiro.akashi@...aro.org>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Johannes Berg <johannes@...solutions.net>,
        Greg KH <gregkh@...uxfoundation.org>, wagi@...om.org,
        dwmw2@...radead.org, rafal@...ecki.pl,
        arend.vanspriel@...adcom.com, rjw@...ysocki.net,
        yi1.li@...ux.intel.com, atull@...nsource.altera.com,
        moritz.fischer@...us.com, pmladek@...e.com,
        emmanuel.grumbach@...el.com, luciano.coelho@...el.com,
        kvalo@...eaurora.org, luto@...nel.org,
        torvalds@...ux-foundation.org, keescook@...omium.org,
        dhowells@...hat.com, pjones@...hat.com, hdegoede@...hat.com,
        alan@...ux.intel.com, tytso@....edu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Mon, Jun 19, 2017 at 09:41:07PM +0200, Luis R. Rodriguez wrote:
> On Mon, Jun 19, 2017 at 09:33:16AM +0200, Johannes Berg wrote:
> > On Sat, 2017-06-17 at 21:38 +0200, Greg KH wrote:
> > 
> > > But we don't accept kernel patches for some mythical future option
> > > that might be happening some time in the future.  Heck, I'm still not
> > > convinced that firmware signing isn't anything more than just some
> > > snakeoil in the first place!
> > 
> > I for one really want the "firmware" signing, because I want to load
> > the regulatory database through this API, and 
> 
> This was my original goal as well... and it was also one of the reasons why
> the API name change would be much better reflective of future possible uses.
> 
> > But honestly, I've been waiting for years for that now and started
> > looking at what it would take to hand-implement that on top of the
> > existing firmware API. Probably not all that much.
> 
> I had proposed changes to do just this long ago, without any new *API*, so we'd
> support firmware signing just as we do with module signing. Simple!
> 
> It was during these discussions that we realized we actually *wanted* to have
> the option to always specify requests with specific signing requirements from
> the start, as such a flexible API became a prerequisite and so I prioritized
> that work first.
> 
> Lets not ignore previous work and prior discussions then, the last effort on this
> front was by AKASHI, and it'd be greatly appreciated if the topic of firmware
> signing was specifically addressed on that thread there [0].

+1
I always appreciate any comments from those who are for and against
my patch (or firmware signing in general) as well.

-Takahiro AKASHI


> [0] https://lkml.kernel.org/r/20170526030609.1414-1-takahiro.akashi@linaro.org
> 
>  Luis