> I just gave this a try with the current code and it worked fine. Don't
> forget to include the command line when invoking lcp_mlehash and to
> re-provision (lcp_writepol) to TPM NV after generating a new policy/policy
> data.
[RJP] Yes it is all working correctly. I am not sure what I was doing wrong
earlier - I must have forgotten a step or something. All good now, thanks.
Ross
From: Cihula, Joseph [mailto:[email protected]]
Sent: Monday, April 13, 2009 5:42 PM
To: Ross Philipson; [email protected]
Subject: RE: Using LCP type unsigned and policy list files
From: Ross Philipson [mailto:[email protected]]
Sent: Friday, April 10, 2009 4:33 PM
To: [email protected]
Subject: [tboot-devel] Using LCP type unsigned and policy list files
I have run into a couple of issues trying to used the unsigned LCP type and
external policy list files. There are basically two things I wanted to ask
about and/or bring up.
1. I am trying to use lcp_crtpol to create a type unsigned policy but there
doesn't seem to be a way to specify more than one mle hash as input. Looking at
the code in crtpol.c for create_policy(), the count of mle hashes seems to
always be 1 though the routine lcp_create_unsigned_poldata() would load
multiple ones if there were any. It looks like only one entry in listdata[] is
ever initialized. Maybe I am missing something - any clarification would be
great.
[JC] The code will create one hash for each hash (20 pairs of hex chars) in
the mle file (as specified by the '-m' option). So to create a file with
multiple hashes, just concatenate the output of lcp_mlehash into the file.
listdata[] is not the lit of hashes, but rather the list of policy elements
(e.g. MLE hashes and/or platform configurations). All MLE hashes will be in
one list.
I just gave this a try with the current code and it worked fine. Don't forget
to include the command line when invoking lcp_mlehash and to re-provision
(lcp_writepol) to TPM NV after generating a new policy/policy data.
2. I came across an odd hang in xen when I put the LCP data module at the end
of the list of modules in grub. If I move the LCP data module say in front of
the sinit module, the hang goes away. This only happens when tboot does an
un-trusted launch (since in the trusted case, it removes sinit and lcp modules
from mbi). It has something to do with the module moving code in __start_xen().
I am going to investigate it further to see if it is a bug in xen (I think it
might be related to the very small size of the LCP data module). Anyway, in
looking at the tboot code I was thinking it might make sense to pop any sinit
and lcp modules out of the mbi module list even in the case where tboot doesn't
to a trusted launch as is the case in a trusted launch. The next level kernel
modules do not need to see these modules whether it is a trusted boot or not.
If folks thinks this is a good idea, I can submit a patch.
[JC] tboot should definitely be removing both the SINIT and policy files
before launching the VMM/kernel regardless of success or failure. A patch
would be greatly appreciated.
Thanks
Ross
Ross Philipson
Senior Software Engineer
Citrix Systems, Inc
14 Crosby Drive
Bedford, MA 01730
781-301-7949
[email protected]<mailto:[email protected]>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
