linux-kernel - Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

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] [day] [month] [year] [list]

Message-ID: <20150520211930.GA23057@wotan.suse.de>
Date:	Wed, 20 May 2015 23:19:30 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	Rusty Russell <rusty@...tcorp.com.au>,
	David Howells <dhowells@...hat.com>,
	Ming Lei <ming.lei@...onical.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Kyle McMartin <kyle@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kees Cook <keescook@...omium.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Takashi Iwai <tiwai@...e.de>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"wireless-regdb@...ts.infradead.org" 
	<wireless-regdb@...ts.infradead.org>,
	linux-wireless <linux-wireless@...r.kernel.org>, jlee@...e.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Bruce Allan <bruce.w.allan@...el.com>,
	Tadeusz Struk <tadeusz.struk@...el.com>,
	John Griffin <john.griffin@...el.com>
Subject: Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when
 fw signing is enabled

On Wed, May 20, 2015 at 11:00:55AM +0200, Paul Bolle wrote:
> On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
> > On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
> > > Well that's be true if FW_LOADER was easy to disable, but its not. You
> > > really gotta try hard to disable it. Not only does it require EXPERT
> > > but also EMBEDDED.
> 
> How does that require EMBEDDED?

Sorry not embedded, not sure where I got that from, for some reason
I though you had mentioned that.

> >  I think its fair to say if you disable FW_LOADER
> > > you know what you are doing and its fair for us then to remove such
> > > selects or depends. Thoughts?
> > 
> > Sure.  I can live with killing all selects/depends on FW_LOADER.
> 
> (Having reread my mail from the day before yesterday once more, I note
> that my suggestion to drop the selects is rather circular. Because it's
> the selects that also make it hard to disable FW_LOADER.)
> 
> So the message is something like: "If you set EXPERT and disable
> FW_LOADER you're on your own. You have to figure out yourself whether
> the configuration you chose builds

I think we can attest that it will build, otherwise we should fix.

> or actually runs correctly.

Whether it will run in this case will depend on whether or not
the firmware was needed or not, if it was it won't. Note that
there is a FW API call which implies "this is optional firmware",
its the request_firmware_direct() call but this call is synchronous,
we have no option for asynchronous behaviour. I intend to add support
for that but that requires a bit of changes. Also, based on my review
its a fair assumption that most calls to the FW APIs mean they need
it. The only ones we can be sure are optional are the ones using
request_firmware_direct().

> Don't
> expect us to care about the issues you run into. And that goes for
> randconfig builds that happen to do that too."

I think its fair to expect us to fix randconfig build issues, but not
runtime issues.

> That might be an acceptable thing to say. The help for EXPERT is pretty
> clear. But I do wonder if this is a first or if this has been done
> before (ie, whether there's a precedent). Because, generally speaking,
> people try rather hard to prevent pointless configurations.

Yeah sure, we even let your system go out of regulatory compliance,
see CFG80211_CERTIFICATION_ONUS, and CFG80211_REG_CELLULAR_HINTS.
Then with CFG80211_INTERNAL_REGDB the parser right now lacks support
for a few new bells and whistles and requires expert knowledge how
to properly build and integrate all new bells and whistles. It seemed
folks were OK with this.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/