[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180312230501.GJ24717@ziepe.ca>
Date: Mon, 12 Mar 2018 17:05:01 -0600
From: Jason Gunthorpe <jgg@...pe.ca>
To: Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>,
Jiandi An <anjiandi@...eaurora.org>, dmitry.kasatkin@...il.com,
jmorris@...ei.org, serge@...lyn.com,
linux-integrity@...r.kernel.org,
linux-ima-devel@...ts.sourceforge.net,
linux-ima-user@...ts.sourceforge.net,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, David Safford <david.safford@...com>
Subject: Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64
On Mon, Mar 12, 2018 at 06:58:45PM -0400, Mimi Zohar wrote:
> On Mon, 2018-03-12 at 15:59 -0600, Jason Gunthorpe wrote:
> > On Mon, Mar 12, 2018 at 05:53:18PM -0400, Mimi Zohar wrote:
> >
> > > Using Kconfig to force the TPM to be builtin is not required, but
> > > helpful. Users interested in IMA-measurement could configure the TPM
> > > as builtin themselves. Without the TPM builtin, IMA goes into TPM-
> > > bypass mode.
> >
> > This issues, broadly speaking, we have lots of TPM drivers, selecting
> > only some to actually support IMA shows we have some kind of problem
> > here.
>
> True, IMA is not selecting the older TPM vendor specific modules, but
> only the newer TPM_TIS and now TPM_CRB modules. That doesn't imply
> that IMA only supports some TPMs. It means that by default, these
> TPMs are builtin. Anyone building a kernel, can select the vendor
> specific TPM to be builtin.
That doesn't help distros, which is the main point of the complaint
with this scheme :)
Jaason
Powered by blists - more mailing lists