On Dec 15, 8:05pm, <travis.gilb...@dell.com> wrote:
} Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot
Good afternoon, I hope the day is going well for everyone.
> > -----Original Message-----
> > From: Gilbert, Travis
> > Sent: Thursday, December 15, 2016 11:38
> > To: tboot-devel@lists.sourceforge.net
> > Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot
> >
> >
> > algorithm mask is 0. Here is the script I'm running to create and write the
> > policy.
> >
> > I'm passing the algorithm in to the lcp2_crtpol command. Why isn't it
> > writing
> > that to the algorithm mask?
> >
> > I'm currently analyzing the policy that was generated to see if, in fact,
> > the
> > hash algorithm mask is 0.
> The hash algorithm mask is 0. If I write all 1s to that area in my
> .pol file, I get past the ACM check. There is a bug in
> lcptools-v2/crtpol.c where none of the alg-masks are ever
> touched. They exist in the lcp_policy_t2 struct, but they're not
> initialized to a usable value. They just inherit the value of all
> zeroes from the memset() call.
Travis, I'm glad that you were able to provide independent
confirmation on this.
Based on the symptoms you were reporting, I suspected you were running
into this issue. As I had previously noted a couple of times on this
list, the tboot LCP tools cannot produce a valid launch control
policy, at least based on the documentation in the TXT SDM and what we
were seeing in the field.
Ning, this is the issue we reported back in July when we shipped
binary dumps of our LC ANY policy to Supreeti while Jeevan was on
sabbatical.
The ACM which Travis is using must be newer then the Broadwell ACM's
since it appears his ACM was able to get him useful diagnostic
information. It appears as if the Broadwell ACM is just resetting the
platform if it runs into any type of anomaly in the PO/LCP without
registering the errorcode in either the hardware error register or the
TB error code index.
Travis, were you able to get TBOOT to report the error code in the
TXT.ERRCODE section of the log or was your BIOS kind enough to give
you an indication of what was going on? Secondly, could you confirm
that after an LCP error that the TB error index gets populated
with the ACM error code.
If not this is a bug since these issues are hard enough to debug
without getting proper diagnostic information out of a botched boot.
> I'm hacking a patch together to get my testing completed. How would
> you devs like me to implement that in a final patch? I can make
> command line arguments to be passed in with those values. I think I
> should also at least make the default match the algorithm being
> passed in on the command line. So if you specify "--alg sha256" then
> lcp_hash_alg_mask should at least match that with 0x0B. If you have
> preferences for command line argument letters to use, speak
> up. Otherwise, I'll pick ones that match with lcptools and that make
> sense.
Given the support of algorithm agility in TPM2 based systems there are
two masks which need to be set. One which selects the valid hashing
algorithms used for measurement and one which selects the valid hash
algorithms for signatures.
Technically, the hash algorithm specification arguements to the
lcp2_crtpol utility shouldn't affect the population of those two
fields, that is a characteristic of the platform. The arguements to
the lcp2_crtol utility specify which algorithm is to be used for
creation of a specific policy and must be a proper subset of the
available algorithms.
Ideally, the lcp2_crtpol utility should be reading the PS policy and
using the algorithm mask in that to populate the equivalent fields in
the PO policy. At least that would be the path least likely to create
bad policies. Obviously, the utility should also reject an attempt to
specify an algorithm which isn't available, at least in an ideal world
where we were trying to be bullet proof.
I'm assuming a proper solution to all of this is too late for the
1.9.5 release.... :-(
Have a good remainder of the week.
Greg
}-- End of excerpt from <travis.gilb...@dell.com>
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: g...@enjellic.com
------------------------------------------------------------------------------
"Remember that when you take down the fishhouse you can't put
the minnows back into the lake, so throw them out on the ice.
Make sure you stomp on any of the live ones so they don't suffer."
-- Fritz Wettstein
At the lake
--
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
