From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH 3/4] stubdom/grub: send kernel measurements to vTPM Date: Tue, 27 Nov 2012 13:53:37 -0500 Message-ID: <50B50C31.6090708@tycho.nsa.gov> References: <50B4D060.9070403@jhuapl.edu> <1354029286-17652-1-git-send-email-dgdegra@tycho.nsa.gov> <1354029286-17652-4-git-send-email-dgdegra@tycho.nsa.gov> <50B50193.3070303@jhuapl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50B50193.3070303@jhuapl.edu> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Matthew Fioravante Cc: "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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