Hi Greg!
Thank you very much for your answer. I hope you are doing well too.
On Sat, May 27, 2017 at 9:16 AM, Dr. Greg Wettstein <g...@wind.enjellic.com>
wrote:
> 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.
At first it was mostly fun, getting to learn this new technology :) Most of
my problems were solved by reading the source code, specs, or by getting a
better understanding of how everything worked. Right now I am starting to
get frustrated by all the obstacles..
>
> > 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 see. So it seems to be a problem with all Broadwell machines.
Have you been able to launch a POLTYPE_LIST?
>
> 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.
>
I am compiling directly from source, so I've got the latest version. I
believe that issue has been patched already.
>
> 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.
>
I haven not gotten that far yet. However, so far I have not got any problem
with the TPM2.0-tools that intel provides.
>
> 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.
>
I see. In this case it is normal hardware. I am thinking on just returning
the NUC and buying something else. Do you know of any system that actually
works with TXT?
>
> 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.
>
Agree. Right now we have to blindly trust intel's ACM, without being able
to read the source code.
>
> 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.
It would be nice to have better tooling and documentation. Maybe even some
reference LCPs (POLTYPE_ANY, MLE2)
>
> > 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.
>
Please, that would be really helpful :)
>
> Good luck with your initiatives.
>
Good luck to you too.
Best Regards,
Marco
>
> 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
