On Wed, 2018-03-14 at 10:25 -0700, James Bottomley wrote:

On Wed, 2018-03-14 at 13:08 -0400, Mimi Zohar wrote:

[..]

quoted

Adding additional support for post IMA-initialization for TPM's built
as kernel modules is clearly not optimal for all of the reasons
provided to now and will be confusing, but could be supported. ?This
delayed loading of the TPM needs to be clearly indicated in both the
audit log and in IMA's measurement list.

Why if the measurement chain isn't broken? ?The way I'm thinking of
implementing it, IMA wouldn't even know.

I'm not sure this is good news.

What would happen is that a
NULL tpm chip in tpm_pcr_read/tpm_pcr_extend would trigger the usual
search for the first TPM but if none were found and we'd booted on an
EFI system, we'd just use the EFI driver to do perform the operation.

If EFI is extending the TPM, will the events be added to the TPM event
log or to the IMA measurement list? ? Up to now the IMA boot aggregate
record includes PCRs from 0 - 7. ?With these PCRs, the boot aggregate
wouldn't change when booting the same kernel. ?Would you change the
boot-aggregate to include these other PCRs?

There's probably a bit of additional subtlety making the kernel and EFI
agree which TPM they're using in a multi-TPM situation.

Agreed

The EFI driver isn't full featured: it only does measurement and
logging, but it looks like that's all IMA needs.

What happens for non EFI systems, when you can't extend the TPM?

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html