* Re: linux-next: Tree for Aug 22 (evm)
2011-08-23 2:09 ` Mimi Zohar
@ 2011-08-23 2:24 ` Arnaud Lacombe
2011-08-24 2:07 ` Mimi Zohar
2011-08-23 2:32 ` Arnaud Lacombe
2011-08-23 23:40 ` Randy Dunlap
2 siblings, 1 reply; 17+ messages in thread
From: Arnaud Lacombe @ 2011-08-23 2:24 UTC (permalink / raw)
To: Mimi Zohar
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
Hi,
On Mon, Aug 22, 2011 at 10:09 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
>> 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@xenotime.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.
>
> Easy, different use cases. The TPM has been around and used for a while,
> not requiring it to be built-in. EVM, a new use case, requires it to be
> built-in.
>
What behavior is expected when TPM is built as a module ? Would you
expect EVM to be accessible ?
>> > 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.
>
> The TPM, crypto, trusted and encrypted keys are tristate. Like the
> LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> the tristates to built-in. The tristate/boolean mismatches aren't
> corrected, when .config is edited directly.
>
well, ... no. 'xconfig' would seem to let you think they have been
changed to 'y', but they have not. I have been able to generate a bad
configuration (TPM module, EVM built-in) using only {menu,x}config.
btw, I never edit the configuration manually, there is a big fat "DO
NOT EDIT" header in the beginning.
Depending on what you expect, one way to fix that is to make EVM
depends on TCG_TPM = y, not just TCG_TPM.
- Arnaud
> Mimi
>
>> > - 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-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-08-23 2:24 ` Arnaud Lacombe
@ 2011-08-24 2:07 ` Mimi Zohar
0 siblings, 0 replies; 17+ messages in thread
From: Mimi Zohar @ 2011-08-24 2:07 UTC (permalink / raw)
To: Arnaud Lacombe
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
On Mon, 2011-08-22 at 22:24 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Aug 22, 2011 at 10:09 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
> >> 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@xenotime.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.
> >
> > Easy, different use cases. The TPM has been around and used for a while,
> > not requiring it to be built-in. EVM, a new use case, requires it to be
> > built-in.
> >
> What behavior is expected when TPM is built as a module ? Would you
> expect EVM to be accessible ?
>
> >> > 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.
> >
> > The TPM, crypto, trusted and encrypted keys are tristate. Like the
> > LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> > the tristates to built-in. The tristate/boolean mismatches aren't
> > corrected, when .config is edited directly.
> >
> well, ... no. 'xconfig' would seem to let you think they have been
> changed to 'y', but they have not. I have been able to generate a bad
> configuration (TPM module, EVM built-in) using only {menu,x}config.
>
> btw, I never edit the configuration manually, there is a big fat "DO
> NOT EDIT" header in the beginning.
>
> Depending on what you expect, one way to fix that is to make EVM
> depends on TCG_TPM = y, not just TCG_TPM.
>
> - Arnaud
Thanks, that seems to work for now. I'd really like to remove the
trusted-key and TCG_TPM dependencies from encrypted keys. Thus removing
the TCG_TPM dependency from EVM. But then, trusted keys could be
enabled differently than encrypted keys.
Is there a way of allowing 'A' not to be dependent on 'B', but if 'B' is
defined, force 'B' to be built-in if 'A' is built-in, or as a module if
'A' is a module?
thanks,
Mimi
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: Tree for Aug 22 (evm)
2011-08-23 2:09 ` Mimi Zohar
2011-08-23 2:24 ` Arnaud Lacombe
@ 2011-08-23 2:32 ` Arnaud Lacombe
2011-08-23 23:40 ` Randy Dunlap
2 siblings, 0 replies; 17+ messages in thread
From: Arnaud Lacombe @ 2011-08-23 2:32 UTC (permalink / raw)
To: Mimi Zohar
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
Hi,
On Mon, Aug 22, 2011 at 10:09 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
>> 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@xenotime.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.
>
> Easy, different use cases. The TPM has been around and used for a while,
> not requiring it to be built-in. EVM, a new use case, requires it to be
> built-in.
>
sorry, I think I misunderstood that last sentence. I assumed the 'it'
was referring to EVM, while taken in context with the previous
sentence, it might as well refers to TPM, in which case you want EVM
to 'depends on TCG_TPM = y'.
- Arnaud
>> > 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.
>
> The TPM, crypto, trusted and encrypted keys are tristate. Like the
> LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> the tristates to built-in. The tristate/boolean mismatches aren't
> corrected, when .config is edited directly.
>
> Mimi
>
>> > - 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-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: Tree for Aug 22 (evm)
2011-08-23 2:09 ` Mimi Zohar
2011-08-23 2:24 ` Arnaud Lacombe
2011-08-23 2:32 ` Arnaud Lacombe
@ 2011-08-23 23:40 ` Randy Dunlap
2011-08-24 2:10 ` Arnaud Lacombe
2 siblings, 1 reply; 17+ messages in thread
From: Randy Dunlap @ 2011-08-23 23:40 UTC (permalink / raw)
To: Mimi Zohar
Cc: Arnaud Lacombe, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
On Mon, 22 Aug 2011 22:09:18 -0400 Mimi Zohar wrote:
> On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
> > 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@xenotime.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.
>
> Easy, different use cases. The TPM has been around and used for a while,
> not requiring it to be built-in. EVM, a new use case, requires it to be
> built-in.
>
> > > 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.
>
> The TPM, crypto, trusted and encrypted keys are tristate. Like the
> LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> the tristates to built-in. The tristate/boolean mismatches aren't
> corrected, when .config is edited directly.
> Mimi:
This isn't a problem about editing .config directly. I haven't done that
here. Also, if 'make xconfig' would convert tristates to built-in, then
so would 'make oldconfig', which is done automatically if configs have
changed (or maybe it's 'make silentoldconfig').
I think that you are going to need to do something like Arnaud suggested
and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
unless you can convince someone that this is a kconfig bug.
> > > - 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 ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: Tree for Aug 22 (evm)
2011-08-23 23:40 ` Randy Dunlap
@ 2011-08-24 2:10 ` Arnaud Lacombe
2011-08-26 12:39 ` Mimi Zohar
0 siblings, 1 reply; 17+ messages in thread
From: Arnaud Lacombe @ 2011-08-24 2:10 UTC (permalink / raw)
To: Randy Dunlap
Cc: Mimi Zohar, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
Hi,
On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> I think that you are going to need to do something like Arnaud suggested
> and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> unless you can convince someone that this is a kconfig bug.
>
dammit... I guess there is...
If you consider the following Kconfig:
config MOD
bool
default y
option modules
config EXPERIMENTAL
bool
default y
menuconfig A
tristate "A"
depends on EXPERIMENTAL
config B
bool "B"
config B0
bool
config C
tristate "C"
depends on B
config C0
tristate
config D
boolean "D"
depends on A && B
select C
select C0
config E
tristate "E"
config F
tristate "F"
select E
B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
(TCG_TPM) allows to set D (EVM), which will select (C). Now,
menuconfig highlight the problem very well. Proceeding as following
A=m, B=y, C=m, E=y, F=y, we ends up having:
<M> A --->
[*] B
{M} C
[*] D
-*- E
<*> F
which translate in the following config:
CONFIG_MOD=y
CONFIG_EXPERIMENTAL=y
CONFIG_A=m
CONFIG_B=y
CONFIG_C=m
CONFIG_C0=m
CONFIG_D=y
CONFIG_E=y
CONFIG_F=y
I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
If you remove D's dependency on 'A', everything works as expected. So
it would seem direct dependency state influence the state of reverse
dependencies...
Will have a look...
- Arnaud
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-08-24 2:10 ` Arnaud Lacombe
@ 2011-08-26 12:39 ` Mimi Zohar
2011-08-26 17:00 ` Randy Dunlap
0 siblings, 1 reply; 17+ messages in thread
From: Mimi Zohar @ 2011-08-26 12:39 UTC (permalink / raw)
To: Arnaud Lacombe
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > I think that you are going to need to do something like Arnaud suggested
> > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> > unless you can convince someone that this is a kconfig bug.
> >
> dammit... I guess there is...
>
> If you consider the following Kconfig:
>
> config MOD
> bool
> default y
> option modules
>
> config EXPERIMENTAL
> bool
> default y
>
> menuconfig A
> tristate "A"
> depends on EXPERIMENTAL
>
> config B
> bool "B"
>
> config B0
> bool
>
> config C
> tristate "C"
> depends on B
>
> config C0
> tristate
>
> config D
> boolean "D"
> depends on A && B
> select C
> select C0
>
> config E
> tristate "E"
>
> config F
> tristate "F"
> select E
>
> B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
> (TCG_TPM) allows to set D (EVM), which will select (C). Now,
> menuconfig highlight the problem very well. Proceeding as following
> A=m, B=y, C=m, E=y, F=y, we ends up having:
>
> <M> A --->
> [*] B
> {M} C
> [*] D
> -*- E
> <*> F
>
> which translate in the following config:
>
> CONFIG_MOD=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_A=m
> CONFIG_B=y
> CONFIG_C=m
> CONFIG_C0=m
> CONFIG_D=y
> CONFIG_E=y
> CONFIG_F=y
>
> I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> If you remove D's dependency on 'A', everything works as expected. So
> it would seem direct dependency state influence the state of reverse
> dependencies...
>
> Will have a look...
>
> - Arnaud
Thanks for looking into this! Instead of changing 'TCG_TPM' to
'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
thanks,
Mimi
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-08-26 12:39 ` Mimi Zohar
@ 2011-08-26 17:00 ` Randy Dunlap
2011-08-27 6:06 ` Arnaud Lacombe
0 siblings, 1 reply; 17+ messages in thread
From: Randy Dunlap @ 2011-08-26 17:00 UTC (permalink / raw)
To: Mimi Zohar
Cc: Arnaud Lacombe, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> > Hi,
> >
> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > > I think that you are going to need to do something like Arnaud suggested
> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> > > unless you can convince someone that this is a kconfig bug.
> > >
> > dammit... I guess there is...
> >
> > If you consider the following Kconfig:
> >
> > config MOD
> > bool
> > default y
> > option modules
> >
> > config EXPERIMENTAL
> > bool
> > default y
> >
> > menuconfig A
> > tristate "A"
> > depends on EXPERIMENTAL
> >
> > config B
> > bool "B"
> >
> > config B0
> > bool
> >
> > config C
> > tristate "C"
> > depends on B
> >
> > config C0
> > tristate
> >
> > config D
> > boolean "D"
> > depends on A && B
> > select C
> > select C0
> >
> > config E
> > tristate "E"
> >
> > config F
> > tristate "F"
> > select E
> >
> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
> > menuconfig highlight the problem very well. Proceeding as following
> > A=m, B=y, C=m, E=y, F=y, we ends up having:
> >
> > <M> A --->
> > [*] B
> > {M} C
> > [*] D
> > -*- E
> > <*> F
> >
> > which translate in the following config:
> >
> > CONFIG_MOD=y
> > CONFIG_EXPERIMENTAL=y
> > CONFIG_A=m
> > CONFIG_B=y
> > CONFIG_C=m
> > CONFIG_C0=m
> > CONFIG_D=y
> > CONFIG_E=y
> > CONFIG_F=y
> >
> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> > If you remove D's dependency on 'A', everything works as expected. So
> > it would seem direct dependency state influence the state of reverse
> > dependencies...
> >
> > Will have a look...
> >
> > - Arnaud
>
> Thanks for looking into this! Instead of changing 'TCG_TPM' to
> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
Yes, linux-next (randconfig) builds are still failing, so we need something
to prevent that.
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-08-26 17:00 ` Randy Dunlap
@ 2011-08-27 6:06 ` Arnaud Lacombe
2011-09-02 0:32 ` Arnaud Lacombe
0 siblings, 1 reply; 17+ messages in thread
From: Arnaud Lacombe @ 2011-08-27 6:06 UTC (permalink / raw)
To: Randy Dunlap
Cc: Mimi Zohar, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
Hi,
On Fri, Aug 26, 2011 at 1:00 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
>
>> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
>> > Hi,
>> >
>> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> > > I think that you are going to need to do something like Arnaud suggested
>> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
>> > > unless you can convince someone that this is a kconfig bug.
>> > >
>> > dammit... I guess there is...
>> >
>> > If you consider the following Kconfig:
>> >
>> > config MOD
>> > bool
>> > default y
>> > option modules
>> >
>> > config EXPERIMENTAL
>> > bool
>> > default y
>> >
>> > menuconfig A
>> > tristate "A"
>> > depends on EXPERIMENTAL
>> >
>> > config B
>> > bool "B"
>> >
>> > config B0
>> > bool
>> >
>> > config C
>> > tristate "C"
>> > depends on B
>> >
>> > config C0
>> > tristate
>> >
>> > config D
>> > boolean "D"
>> > depends on A && B
>> > select C
>> > select C0
>> >
>> > config E
>> > tristate "E"
>> >
>> > config F
>> > tristate "F"
>> > select E
>> >
>> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
>> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
>> > menuconfig highlight the problem very well. Proceeding as following
>> > A=m, B=y, C=m, E=y, F=y, we ends up having:
>> >
>> > <M> A --->
>> > [*] B
>> > {M} C
>> > [*] D
>> > -*- E
>> > <*> F
>> >
>> > which translate in the following config:
>> >
>> > CONFIG_MOD=y
>> > CONFIG_EXPERIMENTAL=y
>> > CONFIG_A=m
>> > CONFIG_B=y
>> > CONFIG_C=m
>> > CONFIG_C0=m
>> > CONFIG_D=y
>> > CONFIG_E=y
>> > CONFIG_F=y
>> >
>> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
>> > If you remove D's dependency on 'A', everything works as expected. So
>> > it would seem direct dependency state influence the state of reverse
>> > dependencies...
>> >
>> > Will have a look...
>> >
>> > - Arnaud
>>
>> Thanks for looking into this! Instead of changing 'TCG_TPM' to
>> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
>> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
>> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
>> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
>
> Yes, linux-next (randconfig) builds are still failing, so we need something
> to prevent that.
>
you may want to try:
git://github.com/lacombar/linux-2.6.git master/kconfig/expr-woes
only the last commit is relevant to the problem, but depend on one
another to get <assert.h>. The rest aims at tidying the expr stuff.
I'm looking for regression it may have introduced.
Thanks,
- Arnaud
ps: I'll most likely be AFK until sunday evening (to be conservative).
> thanks,
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-08-27 6:06 ` Arnaud Lacombe
@ 2011-09-02 0:32 ` Arnaud Lacombe
2011-09-02 1:40 ` Mimi Zohar
0 siblings, 1 reply; 17+ messages in thread
From: Arnaud Lacombe @ 2011-09-02 0:32 UTC (permalink / raw)
To: Randy Dunlap
Cc: Mimi Zohar, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
Hi,
On Sat, Aug 27, 2011 at 2:06 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Fri, Aug 26, 2011 at 1:00 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
>>
>>> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
>>> > Hi,
>>> >
>>> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>>> > > I think that you are going to need to do something like Arnaud suggested
>>> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
>>> > > unless you can convince someone that this is a kconfig bug.
>>> > >
>>> > dammit... I guess there is...
>>> >
>>> > If you consider the following Kconfig:
>>> >
>>> > config MOD
>>> > bool
>>> > default y
>>> > option modules
>>> >
>>> > config EXPERIMENTAL
>>> > bool
>>> > default y
>>> >
>>> > menuconfig A
>>> > tristate "A"
>>> > depends on EXPERIMENTAL
>>> >
>>> > config B
>>> > bool "B"
>>> >
>>> > config B0
>>> > bool
>>> >
>>> > config C
>>> > tristate "C"
>>> > depends on B
>>> >
>>> > config C0
>>> > tristate
>>> >
>>> > config D
>>> > boolean "D"
>>> > depends on A && B
>>> > select C
>>> > select C0
>>> >
>>> > config E
>>> > tristate "E"
>>> >
>>> > config F
>>> > tristate "F"
>>> > select E
>>> >
>>> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
>>> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
>>> > menuconfig highlight the problem very well. Proceeding as following
>>> > A=m, B=y, C=m, E=y, F=y, we ends up having:
>>> >
>>> > <M> A --->
>>> > [*] B
>>> > {M} C
>>> > [*] D
>>> > -*- E
>>> > <*> F
>>> >
>>> > which translate in the following config:
>>> >
>>> > CONFIG_MOD=y
>>> > CONFIG_EXPERIMENTAL=y
>>> > CONFIG_A=m
>>> > CONFIG_B=y
>>> > CONFIG_C=m
>>> > CONFIG_C0=m
>>> > CONFIG_D=y
>>> > CONFIG_E=y
>>> > CONFIG_F=y
>>> >
>>> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
>>> > If you remove D's dependency on 'A', everything works as expected. So
>>> > it would seem direct dependency state influence the state of reverse
>>> > dependencies...
>>> >
>>> > Will have a look...
>>> >
>>> > - Arnaud
>>>
>>> Thanks for looking into this! Instead of changing 'TCG_TPM' to
>>> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
>>> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
>>> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
>>> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
>>
>> Yes, linux-next (randconfig) builds are still failing, so we need something
>> to prevent that.
>>
> you may want to try:
>
> git://github.com/lacombar/linux-2.6.git master/kconfig/expr-woes
>
ping ?
- Arnaud
> only the last commit is relevant to the problem, but depend on one
> another to get <assert.h>. The rest aims at tidying the expr stuff.
> I'm looking for regression it may have introduced.
>
> Thanks,
> - Arnaud
>
> ps: I'll most likely be AFK until sunday evening (to be conservative).
>
>> thanks,
>> ---
>> ~Randy
>> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-09-02 0:32 ` Arnaud Lacombe
@ 2011-09-02 1:40 ` Mimi Zohar
2011-09-02 2:21 ` Arnaud Lacombe
0 siblings, 1 reply; 17+ messages in thread
From: Mimi Zohar @ 2011-09-02 1:40 UTC (permalink / raw)
To: Arnaud Lacombe
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
On Thu, 2011-09-01 at 20:32 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Sat, Aug 27, 2011 at 2:06 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> > Hi,
> >
> > On Fri, Aug 26, 2011 at 1:00 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >> On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
> >>
> >>> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> >>> > Hi,
> >>> >
> >>> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >>> > > I think that you are going to need to do something like Arnaud suggested
> >>> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> >>> > > unless you can convince someone that this is a kconfig bug.
> >>> > >
> >>> > dammit... I guess there is...
> >>> >
> >>> > If you consider the following Kconfig:
> >>> >
> >>> > config MOD
> >>> > bool
> >>> > default y
> >>> > option modules
> >>> >
> >>> > config EXPERIMENTAL
> >>> > bool
> >>> > default y
> >>> >
> >>> > menuconfig A
> >>> > tristate "A"
> >>> > depends on EXPERIMENTAL
> >>> >
> >>> > config B
> >>> > bool "B"
> >>> >
> >>> > config B0
> >>> > bool
> >>> >
> >>> > config C
> >>> > tristate "C"
> >>> > depends on B
> >>> >
> >>> > config C0
> >>> > tristate
> >>> >
> >>> > config D
> >>> > boolean "D"
> >>> > depends on A && B
> >>> > select C
> >>> > select C0
> >>> >
> >>> > config E
> >>> > tristate "E"
> >>> >
> >>> > config F
> >>> > tristate "F"
> >>> > select E
> >>> >
> >>> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
> >>> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
> >>> > menuconfig highlight the problem very well. Proceeding as following
> >>> > A=m, B=y, C=m, E=y, F=y, we ends up having:
> >>> >
> >>> > <M> A --->
> >>> > [*] B
> >>> > {M} C
> >>> > [*] D
> >>> > -*- E
> >>> > <*> F
> >>> >
> >>> > which translate in the following config:
> >>> >
> >>> > CONFIG_MOD=y
> >>> > CONFIG_EXPERIMENTAL=y
> >>> > CONFIG_A=m
> >>> > CONFIG_B=y
> >>> > CONFIG_C=m
> >>> > CONFIG_C0=m
> >>> > CONFIG_D=y
> >>> > CONFIG_E=y
> >>> > CONFIG_F=y
> >>> >
> >>> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> >>> > If you remove D's dependency on 'A', everything works as expected. So
> >>> > it would seem direct dependency state influence the state of reverse
> >>> > dependencies...
> >>> >
> >>> > Will have a look...
> >>> >
> >>> > - Arnaud
> >>>
> >>> Thanks for looking into this! Instead of changing 'TCG_TPM' to
> >>> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
> >>> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
> >>> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
> >>> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
> >>
> >> Yes, linux-next (randconfig) builds are still failing, so we need something
> >> to prevent that.
> >>
> > you may want to try:
> >
> > git://github.com/lacombar/linux-2.6.git master/kconfig/expr-woes
> >
> ping ?
>
> - Arnaud
I assume you want me to test using expr-woes, but I'm not how. Could
you help me here a bit.
(Over the weekend I removed encrypted keys dependency on TCG_TPM.)
thanks,
Mimi
> > only the last commit is relevant to the problem, but depend on one
> > another to get <assert.h>. The rest aims at tidying the expr stuff.
> > I'm looking for regression it may have introduced.
> >
> > Thanks,
> > - Arnaud
> >
> > ps: I'll most likely be AFK until sunday evening (to be conservative).
> >
> >> thanks,
> >> ---
> >> ~Randy
> >> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> >>
> >
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-09-02 1:40 ` Mimi Zohar
@ 2011-09-02 2:21 ` Arnaud Lacombe
2011-09-02 15:01 ` Randy Dunlap
0 siblings, 1 reply; 17+ messages in thread
From: Arnaud Lacombe @ 2011-09-02 2:21 UTC (permalink / raw)
To: Mimi Zohar
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
Hi,
On Thu, Sep 1, 2011 at 9:40 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Thu, 2011-09-01 at 20:32 -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Sat, Aug 27, 2011 at 2:06 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>> > Hi,
>> >
>> > On Fri, Aug 26, 2011 at 1:00 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> >> On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
>> >>
>> >>> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
>> >>> > Hi,
>> >>> >
>> >>> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> >>> > > I think that you are going to need to do something like Arnaud suggested
>> >>> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
>> >>> > > unless you can convince someone that this is a kconfig bug.
>> >>> > >
>> >>> > dammit... I guess there is...
>> >>> >
>> >>> > If you consider the following Kconfig:
>> >>> >
>> >>> > config MOD
>> >>> > bool
>> >>> > default y
>> >>> > option modules
>> >>> >
>> >>> > config EXPERIMENTAL
>> >>> > bool
>> >>> > default y
>> >>> >
>> >>> > menuconfig A
>> >>> > tristate "A"
>> >>> > depends on EXPERIMENTAL
>> >>> >
>> >>> > config B
>> >>> > bool "B"
>> >>> >
>> >>> > config B0
>> >>> > bool
>> >>> >
>> >>> > config C
>> >>> > tristate "C"
>> >>> > depends on B
>> >>> >
>> >>> > config C0
>> >>> > tristate
>> >>> >
>> >>> > config D
>> >>> > boolean "D"
>> >>> > depends on A && B
>> >>> > select C
>> >>> > select C0
>> >>> >
>> >>> > config E
>> >>> > tristate "E"
>> >>> >
>> >>> > config F
>> >>> > tristate "F"
>> >>> > select E
>> >>> >
>> >>> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
>> >>> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
>> >>> > menuconfig highlight the problem very well. Proceeding as following
>> >>> > A=m, B=y, C=m, E=y, F=y, we ends up having:
>> >>> >
>> >>> > <M> A --->
>> >>> > [*] B
>> >>> > {M} C
>> >>> > [*] D
>> >>> > -*- E
>> >>> > <*> F
>> >>> >
>> >>> > which translate in the following config:
>> >>> >
>> >>> > CONFIG_MOD=y
>> >>> > CONFIG_EXPERIMENTAL=y
>> >>> > CONFIG_A=m
>> >>> > CONFIG_B=y
>> >>> > CONFIG_C=m
>> >>> > CONFIG_C0=m
>> >>> > CONFIG_D=y
>> >>> > CONFIG_E=y
>> >>> > CONFIG_F=y
>> >>> >
>> >>> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
>> >>> > If you remove D's dependency on 'A', everything works as expected. So
>> >>> > it would seem direct dependency state influence the state of reverse
>> >>> > dependencies...
>> >>> >
>> >>> > Will have a look...
>> >>> >
>> >>> > - Arnaud
>> >>>
>> >>> Thanks for looking into this! Instead of changing 'TCG_TPM' to
>> >>> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
>> >>> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
>> >>> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
>> >>> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
>> >>
>> >> Yes, linux-next (randconfig) builds are still failing, so we need something
>> >> to prevent that.
>> >>
>> > you may want to try:
>> >
>> > git://github.com/lacombar/linux-2.6.git master/kconfig/expr-woes
>> >
>> ping ?
>>
>> - Arnaud
>
> I assume you want me to test using expr-woes, but I'm not how. Could
> you help me here a bit.
>
> (Over the weekend I removed encrypted keys dependency on TCG_TPM.)
>
Well, at this point, this is not really related to the particular
issue, but to kconfig more generally. I guess I'll just post the
patches on LKML and see if they triggers non-wanted regression.
Thanks,
- Arnaud
> thanks,
>
> Mimi
>
>> > only the last commit is relevant to the problem, but depend on one
>> > another to get <assert.h>. The rest aims at tidying the expr stuff.
>> > I'm looking for regression it may have introduced.
>> >
>> > Thanks,
>> > - Arnaud
>> >
>> > ps: I'll most likely be AFK until sunday evening (to be conservative).
>> >
>> >> thanks,
>> >> ---
>> >> ~Randy
>> >> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>> >>
>> >
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: linux-next: Tree for Aug 22 (evm)
2011-09-02 2:21 ` Arnaud Lacombe
@ 2011-09-02 15:01 ` Randy Dunlap
0 siblings, 0 replies; 17+ messages in thread
From: Randy Dunlap @ 2011-09-02 15:01 UTC (permalink / raw)
To: Arnaud Lacombe
Cc: Mimi Zohar, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
On Thu, 1 Sep 2011 22:21:16 -0400 Arnaud Lacombe wrote:
> Hi,
>
> On Thu, Sep 1, 2011 at 9:40 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Thu, 2011-09-01 at 20:32 -0400, Arnaud Lacombe wrote:
> >> Hi,
> >>
> >> On Sat, Aug 27, 2011 at 2:06 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > On Fri, Aug 26, 2011 at 1:00 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >> >> On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
> >> >>
> >> >>> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> >> >>> > Hi,
> >> >>> >
> >> >>> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >> >>> > > I think that you are going to need to do something like Arnaud suggested
> >> >>> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> >> >>> > > unless you can convince someone that this is a kconfig bug.
> >> >>> > >
> >> >>> > dammit... I guess there is...
> >> >>> >
> >> >>> > If you consider the following Kconfig:
[snip]
> >> >>> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> >> >>> > If you remove D's dependency on 'A', everything works as expected. So
> >> >>> > it would seem direct dependency state influence the state of reverse
> >> >>> > dependencies...
> >> >>> >
> >> >>> > Will have a look...
> >> >>> >
> >> >>> > - Arnaud
> >> >>>
> >> >>> Thanks for looking into this! Instead of changing 'TCG_TPM' to
> >> >>> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
> >> >>> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
> >> >>> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
> >> >>> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
> >> >>
> >> >> Yes, linux-next (randconfig) builds are still failing, so we need something
> >> >> to prevent that.
> >> >>
> >> > you may want to try:
> >> >
> >> > git://github.com/lacombar/linux-2.6.git master/kconfig/expr-woes
> >> >
> >> ping ?
> >>
> >> - Arnaud
> >
> > I assume you want me to test using expr-woes, but I'm not how. Could
> > you help me here a bit.
> >
> > (Over the weekend I removed encrypted keys dependency on TCG_TPM.)
> >
> Well, at this point, this is not really related to the particular
> issue, but to kconfig more generally. I guess I'll just post the
> patches on LKML and see if they triggers non-wanted regression.
Yes, please do that.
> Thanks,
> - Arnaud
>
> > thanks,
> >
> > Mimi
> >
> >> > only the last commit is relevant to the problem, but depend on one
> >> > another to get <assert.h>. The rest aims at tidying the expr stuff.
> >> > I'm looking for regression it may have introduced.
> >> >
> >> > Thanks,
> >> > - Arnaud
> >> >
> >> > ps: I'll most likely be AFK until sunday evening (to be conservative).
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 17+ messages in thread