Re: [PATCH 3/4] stubdom/grub: send kernel measurements to vTPM

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 11/27/2012 01:08 PM, Matthew Fioravante wrote:
> On 11/27/2012 10:14 AM, Daniel De Graaf wrote:
>> This allows a domU with an arbitrary kernel and initrd to take advantage
>> of the static root of trust provided by a vTPM.
> Do you have any documentation updates for how to use it? They could be added to the vtpm documentation if thats the most appropriate location.

Not much documentation is really needed - you just launch a domain with the
pv-grub kernel and a vTPM, and this patch will write the measurements of the
kernel, initrd, and command line to PCRs 4/5, similar to trusted grub on real
hardware.
 
> How exactly does this work? Is it intended for HVM domains whos stubdom is connected to a vtpm? I've never tried to use vtpm with HVMs yet, so I'd be very surprised if it just works. Does it work for PVM domains?
> 
> I'm not terribly familiar with how grub in stubdom works.

This is PV only. The pv-grub stubdom is constructed similar to any other PV domain,
but the pv-grub kernel is specified instead of a normal Linux kernel. The pv-grub
kernel then loads a grub.conf from the guest's disk image and loads the Linux
kernel and initrd specified by the guest; this is more secure than pygrub which
does the loading in dom0, and more flexible than requiring the user to pick from
a list of pre-approved non-malicious kernels. If the pv-grub domain is created on
command by a measured domain builder/initrd combination, you can produce a static
chain of trust extending down to the hardware TPM without involving every UID 0
process in dom0.

[...]
>> +       cmd.pcr = be32(4); // PCR #4 for kernel
>> +       sha_compute(cmd.hash, dom->kernel_blob, dom->kernel_size);
>> +
>> +       tpmfront_cmd(tpm, (void*)&cmd, sizeof(cmd), &resp, &resplen);
>> +
>> +       cmd.pcr = be32(5); // PCR #5 for cmdline
>> +       sha_compute(cmd.hash, cmdline, strlen(cmdline));
>> +       tpmfront_cmd(tpm, (void*)&cmd, sizeof(cmd), &resp, &resplen);
>> +
>> +       cmd.pcr = be32(5); // PCR #5 for initrd
>> +       sha_compute(cmd.hash, dom->ramdisk_blob, dom->ramdisk_size);
>> +       tpmfront_cmd(tpm, (void*)&cmd, sizeof(cmd), &resp, &resplen);
>> +
>> +       shutdown_tpmfront(tpm, 1);
>> +}
> Does this actually work? vtpm-stubdom will shut itself down when the frontend tpm disconnects. Is it really ok to connect and disconnect these devices at will?

Hmm, apparently this part may depend on the change from tpmback_req to
tpmback_req_any to avoid the shutdown on disconnect. That might not be
required (shutdown for reconfigure shouldn't start returning NULL for
requests) but I also haven't tested that it works without #4.

[...]
>> +++ b/stubdom/grub/sha1.c
[...]
> There also exists a sha1 routine in polarssl. You can just link in the polarssl sha1 object file without the entire library. This is what vtpm-stubdom and vtpmmgrdom do to get the crypto pieces they need. Checkout their makefiles for details.
> Is there any reason using polarssl would be sub-optimal?

No, I think rewriting this to use the polarssl functions would be useful; I
didn't notice the polarssl function was available when this patch was created.

-- 
Daniel De Graaf
National Security Agency