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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ