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: <20160803145014.GO3296@wotan.suse.de>
Date:	Wed, 3 Aug 2016 16:50:14 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	gregkh@...uxfoundation.org, ming.lei@...onical.com,
	akpm@...ux-foundation.org, mmarek@...e.com
Cc:	linux-kernel@...r.kernel.org, markivx@...eaurora.org,
	stephen.boyd@...aro.org, zohar@...ux.vnet.ibm.com,
	broonie@...nel.org, tiwai@...e.de, johannes@...solutions.net,
	chunkeey@...glemail.com, hauke@...ke-m.de,
	jwboyer@...oraproject.org, dmitry.torokhov@...il.com,
	dwmw2@...radead.org, jslaby@...e.com,
	torvalds@...ux-foundation.org, luto@...capital.net,
	fengguang.wu@...el.com, rpurdie@...ys.net,
	j.anaszewski@...sung.com, Abhay_Salunke@...l.com,
	Julia.Lawall@...6.fr, Gilles.Muller@...6.fr, nicolas.palix@...g.fr,
	teg@...m.no, dhowells@...hat.com,
	martin.blumenstingl@...glemail.com, nbd@....name,
	mark.rutland@....com, robh+dt@...nel.org,
	arend.vanspriel@...adcom.com, dev@...sin.me, kvalo@...eaurora.org,
	"Luis R. Rodriguez" <mcgrof@...nel.org>
Subject: Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > The firmware API has had some issues a while ago, some of this is
> > > > not well documented, and its still hard to grasp. This documents
> > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > for issues, and annotations to help us with our effort to finally
> > > > compartamentalize that pesky usermode helper.
> > > > 
> > > > Previously this was just one patch, the grammar rule to help
> > > > find request firmware API users on init or probe, this series
> > > > extends that effort with usermode helper grammar rules, and some
> > > > annotations and documentation on the firmware_class driver to
> > > > avoid further issues. Documenting the usermode helper and making
> > > > it clear why we cannot remove it is important for analysis for
> > > > the next series which adds the new flexible sysdata firmware API.
> > > > 
> > > > This series depends on the coccicheck series which enables
> > > > annotations on coccinelle patches to require a specific
> > > > version of coccinelle [0], as such coordination with Michal is
> > > > in order.
> > > 
> > > Michal is out until July 11, and upon further thought such coordination
> > > is not need, the annotation is in place as comments and as such
> > > merging this now won't have any negative effects other than the version
> > > check. Also the patches in question for the coccicheck change are all
> > > acked now and I expect them to be merged anyway.
> > > 
> > > Which tree should firmware changes go through ?
> > > 
> > > > This series is also further extended next with the new sydata
> > > > API, the full set of changes is available on my linux-next tree [1].
> > > > 
> > > > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > > > every 0-day iteration, it runs rather fast and it should help police
> > > > against avoiding futher explicit users of the usermode helper.
> > > 
> > > And if we are going to merge this anyone oppose enabling hunting
> > > for further explicit users of the usermode helper using grammar through
> > > 0-day ?
> > 
> > *Poke*
> 
> *Re-poke*

Re-re-poke.

The scripts/coccicheck changes are now merged on Linus' tree, so these patches
have no other pending changes upstream.

Who's tree can this go through or is this too late now?
Andrew can these go through your tree?

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ