lkml.org 
[lkml]   [2015]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled
From
Date
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@suse.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@ergon ~/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



\
 
 \ /
  Last update: 2015-05-07 11:21    [W:0.081 / U:1.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site