On May 26, 3:27pm, Marco Vanotti wrote:
} Subject: Re: [tboot-devel] Questions about Launch Control Policies
> Hi Ning,
Hi Marco, I hope this note finds your weekend going well.
I've been watching this thread go by but have been swamped with a
number of other issues and haven't been able to compose a reply.
First a reflection from a 50K perspective.
We have expended significant engineering time and resources on TPM2
based TXT systems in order to build trusted platforms for clients. We
have close to a year of engineering time into developing support and
infrastructure for next generation security systems based on TXT/TPM2,
at this point in time we still are struggling to address all of the
issues we have identified on these platforms.
So don't feel like you are struggling inordinately.
> After a bit of tinkering with the NUC, I've come to a problem with
> that attributes. As I mentioned in another email, I'm having trouble
> with an Invalid RSDP once I add files to multiboot in the NUC. A
> side effect of that problem + using 0x4000A for the PO LCP is that
> the TPM gets into lockout mode and I have to clear ownership in
> order to use the same index again.
>
> ... [ error codes and information removed ] ...
>
> So I believe using the NO_DA flag while defining the policy is a
> requirement. Maybe there's a problem with my bios or sinit module?
> Do you know how can I debug that problem?
>
> I have another system and the policy works there, it has
> tpm_nv_index_set = 0, and has the NO_DA attribute set (0x204000A)
We identified and reported the specific problem you are facing with
the Broadwell NUC about 11 months ago.
There appears to be an architecture specific issue with the Broadwell
TPM2/TXT platforms. If the PO NVram index is created with attributes
based on what is documented in the TXT Software Development Manual
(SDM) the SINIT AC module will issue a hardware reset after TBOOT
initiates GETSEC[SENTER] processing.
We currently have our Broadwell NUC reference platforms (the same as
yours) executing a measured launch with a PO LCP_ANY policy but the
NO_DA bit must be cleared. I don't have one of those machines on the
bench right now, I am also a hundred miles away from our lab and can't
hook one up, but I will do so and dump out the attributes from one of
the machines after I get back into town after the weekend and send it
to you if you would like.
I assume you are using the 'production' release of TBOOT? On TPM2
based systems there is a device initialization ordering problem which
causes TBOOT to de-reference a NULL pointer and essentially read
random memory when it populates the TPM information structure. This
will cause the first (pre-GETSEC[SENTER] phase) of TBOOT to use the
wrong NVram index locations.
We need to implement a PCR based LCP PO policy but we haven't tangled
with that can of worms yet. Given the problems of even getting basic
LCP_ANY working it will be interesting to see how the ACM's deal with
the TPMS quotes.
In the FWIW department, for the benefit of the community, there is
also a probable hardware problem with TBOOT S3 sleep state processing.
At this time it isn't possible to enter and resume from S3 and have
TBOOT properly validate its protected memory regions.
Until we can get this issue run down it is difficult to know how
Linux/TBOOT will deal with the TPM resource manager which has been
included in recent kernels.
With respect to the RSDP issue you are running into. I believe the
link you posted was part of a thread in which we were attempting to
address a problem which a young engineer from HP Enterprise was
working on which was probably a 'custom' hardware configuration. I
believe we got him pointed to someone inside Intel but never got any
feedback on how the problem got addressed.
At the risk of editorializing a bit, it seems that Intel largely looks
upon TBOOT as a community project. Given the issues which we have run
into, its somewhat hard to believe that VMware and other commercial
vendors would be using this to supported trusted computing pools and
the like for commercial customers.
I believe there is plenty of engineering talent circulating around
this technology, but quite frankly given the intent of the technology,
it is purposefully designed to be non-debuggable. If we are going to
treat this as a community project and fix bugs, the ACM code needs to
be available in source form. I'm not sure how any of this can be
effectively debugged in the current environment.
At this point in time the jury is out as to whether or not we will be
proceeding forward with targeting TXT/TPM2 development in the future.
Given the utility of this technology and the desperate industry need
for better security guarantees the barriers associated with advancing
initiatives are decidedly perplexing.
It is an amazing chicken and egg problem. There is no market to
consume this security technology so there appears to be little
incentive to invest resources in supporting it, thats certainly
understandable. Unfortunately, products are not going to emerge
unless they can be developed which is proving to be a challenge on
what will be the operative hardware platform for the foreseeable
future.
> Have a nice weekend!
>
> Best Regards,
> Marco
Hopefully the above information and reference points are helpful. I
will get a dump of the LCP PO NVram attributes, which are working on
Broadwell NUC, off to you in case that would be helpful.
Good luck with your initiatives.
Greg
}-- End of excerpt from Marco Vanotti
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
------------------------------------------------------------------------------
"Man, despite his artistic pretensions, his sophistication and many
accomplishments, owes the fact of his existence to a six-inch layer of
topsoil and the fact that it rains."
-- Anonymous writer on perspective.
GAUSSIAN quote.
------------------------------------------------------------------------------
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
