public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Arnaud Lacombe <lacombar@gmail.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Mimi Zohar <zohar@us.ibm.com>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-kbuild@vger.kernel.org
Subject: Re: linux-next: Tree for Aug 22 (evm)
Date: Tue, 23 Aug 2011 22:07:29 -0400	[thread overview]
Message-ID: <1314151649.3247.43.camel@localhost.localdomain> (raw)
In-Reply-To: <CACqU3MV-MfWxvVebcxiJK8BmxHG8epf=0bpsL7qoska65aVzSw@mail.gmail.com>

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


  reply	other threads:[~2011-08-24  2:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110822145304.980529cb921e5f1321c622da@canb.auug.org.au>
2011-08-22 19:53 ` linux-next: Tree for Aug 22 (evm) Randy Dunlap
2011-08-22 20:18   ` Arnaud Lacombe
2011-08-23  0:47   ` Arnaud Lacombe
2011-08-23  0:49     ` Randy Dunlap
2011-08-23  2:09       ` Mimi Zohar
2011-08-23  2:24         ` Arnaud Lacombe
2011-08-24  2:07           ` Mimi Zohar [this message]
2011-08-23  2:32         ` Arnaud Lacombe
2011-08-23 23:40         ` Randy Dunlap
2011-08-24  2:10           ` Arnaud Lacombe
2011-08-26 12:39             ` Mimi Zohar
2011-08-26 17:00               ` Randy Dunlap
2011-08-27  6:06                 ` Arnaud Lacombe
2011-09-02  0:32                   ` Arnaud Lacombe
2011-09-02  1:40                     ` Mimi Zohar
2011-09-02  2:21                       ` Arnaud Lacombe
2011-09-02 15:01                         ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1314151649.3247.43.camel@localhost.localdomain \
    --to=zohar@linux.vnet.ibm.com \
    --cc=lacombar@gmail.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=sfr@canb.auug.org.au \
    --cc=zohar@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox