On Wed, Jan 09, 2019 at 10:34:42AM -0800, Andy Lutomirski wrote: > I suppose I should go read the 2.0 spec. I’ve read the 1.2 spec, but I > always assumed that 2.0 was essentially a superset of 1.2 > functionality.
They are essentially different protocols. No real compatibility. > Can the kernel filter TPM 2.0 operations? If so, then a signature > that the kernel would have prevented user code from generating is de > facto an attestation that the kernel generated it (or that the kernel > was compromised, which is sort of equivalent). You shoud look into TPM resource manager that I implemented with great work from James on session swapping and see how far it scales what you have in mind. It is currently exposed only to the user space but could be easily made an in-kernel API. Side-topic: right now the TPM driver can be compiled as a module when its APIs are not used by the kernel (namely IMA and trusted keys) with some Kconfig magic. Since it looks like that there will be even more customers, I think it would make sense to make the TPM driver core as part of the core kernel (device drivers for different types of chips could still be modules). I've proposed this before maybe two times, but it has always been rejected. /Jarkko
