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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20170619194107.GI21846@wotan.suse.de>
Date:   Mon, 19 Jun 2017 21:41:07 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.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,
        takahiro.akashi@...aro.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: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].

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

 Luis