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

Message-ID: <1430988137.8171.58.camel@x220>
Date:	Thu, 07 May 2015 10:42:17 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	rusty@...tcorp.com.au, dhowells@...hat.com, ming.lei@...onical.com,
	seth.forshee@...onical.com, kyle@...nel.org,
	akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
	keescook@...omium.org, casey@...aufler-ca.com, tiwai@...e.de,
	mjg59@...f.ucam.org, wireless-regdb@...ts.infradead.org,
	linux-wireless@...r.kernel.org, jlee@...e.com,
	linux-kernel@...r.kernel.org,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	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, 2015-05-06 at 11:33 +0800, Herbert Xu wrote:
> On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@...e.com>
> > 
> > We're going to add firmware module signing support, but when we do
> > this we end up with the following recursive dependency. Fix this by
> > just depending on FW_LOADER, which is typically always enabled
> > anyway.
> > 
> > mcgrof@...on ~/linux-next (git::master)$ make allnoconfig
> > scripts/kconfig/conf  --allnoconfig Kconfig
> > crypto/Kconfig:15:error: recursive dependency detected!
> > crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> > init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> > drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> > drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> > drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> > drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> 
> This doesn't look like a real cycle to me so perhaps we can fix
> kbuild to understand this?

(Dependency circles involving selects still hurt my brain.)

Perhaps Luis should have another look at 02/12. See that patch adds this
Kconfig entry to init/Kconfig:
    config SYSDATA_SIG
	def_bool y
	select SYSTEM_TRUSTED_KEYRING
	select KEYS
	select CRYPTO
	select ASYMMETRIC_KEY_TYPE
	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
	select PUBLIC_KEY_ALGO_RSA
	select ASN1
	select OID_REGISTRY
	select X509_CERTIFICATE_PARSER

As far as I can see this is not enclosed in anything that adds any
dependencies. So that basically means that SYSDATA_SIG will always be
set, for all architectures (because I think all arches source
init/Kconfig). That should make it a pretty pointless symbol (except for
the fact that it does trigger all those selects).

The same patch also adds
	select SYSDATA_SIG

to the entry for MODULE_SIG. But to me that looks like a nop, because
SYSDATA_SIG will be set anyhow. So, but this is just I guess, the
problem might go away if
	def_bool y

is changed to just
	bool

(Note that I haven't actually tested anything here, and it wouldn't be
the first time my reasoning about Kconfig patches is completely off.)

And, whatever the value of my analysis, adding a Kconfig problem in
02/12 just to fix it in 03/12 is a bit silly. I think the patches should
be squashed if the problem can't be solved any other way.


Paul Bolle

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