linux-kernel - Re: linux-next: Tree for Aug 22 (evm)

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: <CACqU3MWfKji5BcGRmwO_Y4_15oOq7Trw3u6j1g2meFAaG-s9-w@mail.gmail.com>
Date:	Tue, 23 Aug 2011 22:10:24 -0400
From:	Arnaud Lacombe <lacombar@...il.com>
To:	Randy Dunlap <rdunlap@...otime.net>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	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)

Hi,

On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@...otime.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
--
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/