Re: [tpmdd-devel] [PATCH] TPM: Fixup pubek sysfs file

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Mon, 2009-09-14 at 13:46 -0600, Jason Gunthorpe wrote: 
> On Mon, Sep 14, 2009 at 03:23:09PM -0400, Jonathan M. McCune wrote:
> 
> >> Can anyone think of a reason why the PCRs should be accessed from
> >> sysfs? I can't. They are only really useful in connection with other
> >> complex TPM operations. Userspace can fully access them using the
> >> relevant TPM calls.

> > Fair enough, though they are useful in combination with IMA and as a  
> > sanity check that the driver is working correctly.

The IMA ltp testsuite currently uses the sysfs PCR values 0-7 to
validate the boot aggregate, the first measurement in the the IMA
measurement list. 

> [..]
> > IMA can leverage the ability to read and extend PCRs, and its security  
> > properties derive from that functionality being a part of the kernel.  
> > PCR reading is currently part of the TPM driver in 
> > drivers/char/tpm/tpm.c.
> 
> Sanzzy
> 
> > Thus, to the question, "Can we remove the ability of the kernel to send  
> > TPM commands such as GetCapability and PCRRead?" I believe the answer is  
> > no. Or at least, not without causing a lot of work for the IMA system.

Definitely! On boot, IMA reads pcr 0-7 to calculate the boot aggregate.
IMA then extends the PCR, normally PCR-10, with the boot aggregate and
stores it as the first measurement in the IMA measurement list. Each
subsequent measurement, based on policy, extends the PCR and is appended
to the IMA measurement list. 
  
> > Although it may be worth discussing whether this functionality should be  
> > moved from the driver into IMA.

Are you really suggesting moving the tpm_pcr_read()/extend() to IMA?
Why?

> Fair enough, fortunately TPM_PCRRead and TPM_Extend are two of the
> simplest commands. As has been done special casing the fixed size
> messages is easy and robust.

Mimi