Re: [Qemu-devel] [PATCH] hw/misc: Add simple measurement hardware

[Matthew Garrett]

On Fri, Jul 15, 2016 at 11:11 AM, Stefan Berger <address@hidden> wrote:
>
> Are you also providing a measurement log that goes along with these PCR 
> extensions? Like a measurement log we have in the TCPA ACPI table? Just 
> measurements without knowing what was measured wouldn't be all that helpful. 
> Typically recipients of the measurement list would inspect the individual 
> measurements and replay the extensions to come up with the same state of the 
> PCRs that was quoted (signed) by the TPM. Also, are you going to instrument 
> Linux IMA to use this device? And the list goes on into higher level tools 
> that may work with a measurement list from 
> /sys/kernel/security/{tpm0,ima}/*_measurement_list and assume there's a 
> /dev/tpm0 there that can issue a quote with the AIK. Well, one problem is 
> there's little traction for the vTPM but this device here will require new 
> support in existing tools.


Yes, the firmware will build a log - right now I'm using the TCPA
format. However, the initial measurements from qemu aren't being
handed over to the firmware, so I need to fix that. There's no
fundamental difficulty in adding IMA support, I have a small driver
that can register with enough of the TPM layer to allow its extend
calls to work. I'm not too worried about the existing tooling not
working, to be honest. Making that work would require the hypervisor
to be able to provide a signed quote in TPM format, and that seems
like a much harder sell.

>
> Typically the TPM is there for the reason: it is a hardware root of trust 
> that signs the current state of the PCRs that were accumulated by 
> measurements starting early on during BIOS init. Now with this device, apart 
> from exposing this via HMP, how would one be sure that, if the current list 
> of the PCRs is presented to an attesting client, that the kernel or 
> attestation server not just completely fake the state of the PCRs? My 
> assumption here is that the state of this device's PCRs will be exposed to 
> user level application that can then use this in some form of attestation, 
> right?


Userspace will be able to grab it, but the idea is that the hypervisor
API will allow a copy to be obtained - either a signed copy from the
local API endpoint, or directly via a remote API endpoint. The guest
won't be able to fake the former case, and isn't involved at all in
the latter case.