[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1520539561.3605.92.camel@linux.vnet.ibm.com>
Date: Thu, 08 Mar 2018 15:06:01 -0500
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: Jiandi An <anjiandi@...eaurora.org>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Jason Gunthorpe <jgg@...pe.ca>
Cc: 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
Subject: Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64
On Thu, 2018-03-08 at 12:42 -0600, Jiandi An wrote:
> So from the discussion, I hear James suggests to overhaul the current
> IMA driver to not do measurement (calling tpm_pcr_read(), etc) until
> after initrd phase so TPM drivers can be built as modules.
>
> I hear Mimi insists TPM drivers should be built-in when IMA driver is
> enabled and set to Y in Kconfig.
>
> Do we have a consensus on which way we should go?
>
> I'm no expert on IMA and its driver. James, will you be kind enough
> to look into overhauling the IMA driver to not measure until after
> initrd phase if that's the consensus on resolving this?
IMA selecting the TPM forces the TPM to be builtin. There's nothing
keeping you from directly configuring the TPM driver as builtin.
For remote attestation to validate the IMA measurement list against
the PCRs, the existing "ima_tcb" and "ima_policy=tcb" builtin policies
require the TPM to be builtin.
Not building the TPM into the kernel will also affect EVM.
I don't have a problem accepting your patch now; and if/when there is
a real use case for building the TPM driver as a kernel module for use
with IMA-measurement, accepting those changes then.
Mimi
Powered by blists - more mailing lists