[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110822174958.73dd96c7.rdunlap@xenotime.net>
Date: Mon, 22 Aug 2011 17:49:58 -0700
From: Randy Dunlap <rdunlap@...otime.net>
To: Arnaud Lacombe <lacombar@...il.com>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Mimi Zohar <zohar@...ibm.com>, linux-next@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, linux-kbuild@...r.kernel.org
Subject: Re: linux-next: Tree for Aug 22 (evm)
On Mon, 22 Aug 2011 20:47:00 -0400 Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@...otime.net> wrote:
> > On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
> >
> >> Hi all,
> >>
> >> [The kernel.org mirroring is a bit low today]
> >
> > (on x86_64:)
> >
> > When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
> > CONFIG_ENCRYPTED_KEYS=m, the build fails with:
> >
> You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
> 'm'. That said, correct me if I'm wrong, but we currently have:
Yes, it was 'm'.
> menuconfig TCG_TPM
> tristate "TPM Hardware Support"
>
> [...]
>
> config EVM
> boolean "EVM support"
> depends on SECURITY && KEYS && TCG_TPM
>
> which seems terribly broken to me... How can you have a built-in
> feature, which depends on another potentially-not-built-in feature ?
Yup.
> If you change EVM to 'tristate', you will see that you are not allowed
> to make it built-in if TCG_TPM is not built-in.
Right.
> - Arnaud
>
> > (.text+0x378aa): undefined reference to `key_type_encrypted'
> > evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
> > evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
> > evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
> > evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
> > (.text+0x37b4b): undefined reference to `crypto_shash_update'
> > (.text+0x37c61): undefined reference to `crypto_shash_update'
> > (.text+0x37cb9): undefined reference to `crypto_shash_update'
> >
> > even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
> > and even after I add "select CRYPTO_HASH2".
> >
> > Is this because EVM is bool and kconfig is confused about 'select's
> > when a bool is selecting tristates? Shouldn't the tristates become
> > 'y' instead of 'm' if they are selected by a bool that is 'y'?
> >
> >
> > xconfig shows these symbol values:
> >
> > Symbol: EVM [=y]
> > Type : boolean
> > Prompt: EVM support
> > Defined at security/integrity/evm/Kconfig:1
> > Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
> > Location:
> > -> Security options
> > Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
> >
> >
> > Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
> > lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
> > symbol checking that is confused?
> >
> there is definitively an underlying min/max, but I would not point
> finger too fast.
Thanks for your help.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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/
Powered by blists - more mailing lists