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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel