Re: [tboot-devel] Questions about Launch Control Policies

2017-06-02 Thread Dr. Greg Wettstein 
On May 30, 12:46pm, Marco Vanotti wrote:
} Subject: Re: [tboot-devel] Questions about Launch Control Policies

> Hi Greg!
> 
> Thank you very much for your answer. I hope you are doing well too.

Good morning Marco, I hope the end of the week is going well for you.
Sorry for the delay in responding but I needed to get some equipment
re-arranged in order to answer your e-mail.

> 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..

Indeed.

Given the spectrum of challenges from poor OEM support to hardware
issues and tooling it is difficult to understand how the industry
can move forward implementing getter security guarantees which appear
to be desperately needed.

Once again it appears to be a chicken and egg problem.  There appears
to be little interest in supporting the technology secondary to
insufficient 'market pull/demand' yet it is difficult to understand
how markets can develop with the type of barriers associated with
development, particularly in the TPM2 era.

> > > 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?

We couldn't get a Broadwell based machine to boot if the PO NVram
index location was created.  Once we determined that there appears to
be an undocumented micro-architectural dependency we were able to get
Broadwell machines to boot with a simple LCP_ANY policy.

At that point we started focusing on Skylake platforms since Broadwell
was already 'old' at that time... :-)( We ran into OEM issues on
Skylake surrounding what appears to be issues with respect to whether
or not the motherboard OEM's are properly provisioning TXT based
platforms.

We shifted our a

Re: [tboot-devel] Questions about Launch Control Policies

2017-05-30 Thread Marco Vanotti 
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. Please send
me the attributes if you can :)  The attribtes 0x4000A seem to work,
however, when TXT fail a couple of times, the TPM gets in DA LOCKDOWN mode
and I have to clear it (which I can only do by changing a jumper in the
mother to get into recovery mode).

Side question: 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

Re: [tboot-devel] Questions about Launch Control Policies

2017-05-30 Thread Marco Vanotti 
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 neve

Re: [tboot-devel] Questions about Launch Control Policies

2017-05-27 Thread Dr. Greg Wettstein 
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 ap

Re: [tboot-devel] Questions about Launch Control Policies

2017-05-25 Thread Marco Vanotti 
Hi Ning,

Thank you for your answer.

1) I can't read the index, I believe it's because of the attributes (I
would need owner_read flag) I'm doing:

# tpm2_nvread -x 0x141 -a 0x4001 -s 10
Failed to read NVRAM area at index 0x141 (20971521).Error:0x149

# tpm2_rc_decode 0x149
error layer
  hex: 0x0
  identifier: TSS2_TPM_ERROR_LEVEL
  description: Error produced by the TPM
format 0 error code
  hex: 0x49
  name: TPM_RC_NV_AUTHORIZATION
  description: NV access authorization fails in command actions (this
failure does not affect lockout.action)

This issue occurs in an Intel NUC NUC5i5MYHE, with "5th_gen_i5_i7_SINIT_79.BIN"
(downloaded from the Intel website). The bios is up to date.

I was able to test this on a different server and it doesn't give me the
error (same policy).

2) Ok. Thanks! I was trying to see whether I could see things changing with
a POLTYPE_ANY. I couldn't find anything on the Intel TXT Guide saying that
the capabilities won't be extended on TPM 2.0 (I might have missed it too
:)).

Thank you for your reply!

Best Regards,
Marco



On Thu, May 25, 2017 at 6:58 AM, Sun, Ning <ning@intel.com> wrote:

> For question1: PO NV Index attribute definition is correct, did you see
> this issue when reading from the index? What was the platform and SINIT ACM
> used in finding this issue?
>
>
>
> For question2: this is correct by design, OsSinitData_Capabilities bit in
> PolicyControl works only with TPM1.2 and legacy PCR mapping.
>
> For details/authorities PCR mapping, OsSinitData.Capabilities are always
> extended into PCR17 and have special event for it.
>
>
>
> -Ning
>
>
>
>
>
> *From:* Marco Vanotti [mailto:mvano...@google.com]
> *Sent:* Tuesday, May 23, 2017 10:15 PM
> *To:* Sun, Ning <ning....@intel.com>
> *Cc:* tboot-devel@lists.sourceforge.net
>
> *Subject:* Re: [tboot-devel] Questions about Launch Control Policies
>
>
>
> Thanks for your answer, Ning.
>
>
>
> I have been using tpm2.0-tools and tpm2.0-TSS to work with the TPM. They
> have been very useful so far :).
>
>
>
> I have a couple more questions regarding the Intel TXT Guide:
>
>
>
> The Intel TXT Guide (Appendix J "TPM NV") says that the NVRAM PO Index
> should have the following attributes:
>
> - TPMA_NV_OWNERWRITE
>
> - TPMA_NV_POLICYWRITE
>
> - TPMA_NV_AUTHREAD
>
> - TPMA_NV_NO_DA
>
>
>
> That sets of attributes translate to 0x204000A, but that results in a
> 0xc0081c41 TXT Error (ERR_TPM_NV_INDEX_INVALID_PO_ATTR). I removed the
> TPMA_NV_NO_DA flag and it ended up working. What would the correct solution
> for this issue be?
>
>
>
> The Policy Control field in the LCP has a field that specifies whether
> the OS INIT DATA Capabilities should be extended or not. I tried changing
> that field in my PO LCP, but that didn't make a difference: the capabilites
> are always extended, regardless of the value in the field. I can see that
> my Policy is being read by checking the TPM Event log (type 0x414 tells me
> that my index is being read, and type 0x40c shows that my policy control is
> being loaded). I was playing with this to see the effect of changing things
> in the policy.
>
>
>
> These are minor issues that I are not blocking me, but I would like to get
> an answer to better understand how TXT works.
>
>
>
> Best Regards,
> Marco
>
>
>
> On Tue, May 23, 2017 at 5:12 PM, Sun, Ning <ning@intel.com> wrote:
>
> Hi Marco,
>
>
>
> Thanks for the write-up, you got most of the answers correct for your
> questions.
>
>
>
> Both lcptools and lcptools-v2 folders (in tboot source package) are for
> LCP V2 on TPM 1.2 platforms
>
>
>
> Folder lcp-gen2 is for LCP V3 creation on TPM 2.0 platform, so far tboot
> does not provide tpm 2.0 tools to write the LCP to TPM nv index, there are
> TPM 2.0 TSS and tools from Intel as well, see below.
>
>
>
> For tboot VLP, there is a default VLP in tboot source code, if there is no
> VLP found from TPM NV index, tboot will apply the default VLCP.
>
>
>
> For TPM 2.0 TSS and tools, here are the website for your reference:
>
>
>
> https://github.com/01org/TPM2.0-TSS
>
>
>
> https://github.com/01org/tpm2.0-tools
>
>
>
> -Ning
>
>
>
> *From:* Marco Vanotti [mailto:mvano...@google.com]
> *Sent:* Tuesday, May 23, 2017 1:32 PM
> *To:* tboot-devel@lists.sourceforge.net
> *Subject:* Re: [tboot-devel] Questions about Launch Control Policies
>
>
>
> Hi All!
>
>
>
> After reading a lot of documentation [*], I think I figured out the
> answers to some of the questions. I would like to confirm if what I think
> is correct.
>

Re: [tboot-devel] Questions about Launch Control Policies

2017-05-23 Thread Marco Vanotti 
Thanks for your answer, Ning.

I have been using tpm2.0-tools and tpm2.0-TSS to work with the TPM. They
have been very useful so far :).

I have a couple more questions regarding the Intel TXT Guide:

The Intel TXT Guide (Appendix J "TPM NV") says that the NVRAM PO Index
should have the following attributes:
- TPMA_NV_OWNERWRITE
- TPMA_NV_POLICYWRITE
- TPMA_NV_AUTHREAD
- TPMA_NV_NO_DA

That sets of attributes translate to 0x204000A, but that results in a
0xc0081c41 TXT Error (ERR_TPM_NV_INDEX_INVALID_PO_ATTR). I removed the
TPMA_NV_NO_DA flag and it ended up working. What would the correct solution
for this issue be?

The Policy Control field in the LCP has a field that specifies whether
the OS INIT DATA Capabilities should be extended or not. I tried changing
that field in my PO LCP, but that didn't make a difference: the capabilites
are always extended, regardless of the value in the field. I can see that
my Policy is being read by checking the TPM Event log (type 0x414 tells me
that my index is being read, and type 0x40c shows that my policy control is
being loaded). I was playing with this to see the effect of changing things
in the policy.

These are minor issues that I are not blocking me, but I would like to get
an answer to better understand how TXT works.

Best Regards,
Marco

On Tue, May 23, 2017 at 5:12 PM, Sun, Ning <ning@intel.com> wrote:

> Hi Marco,
>
>
>
> Thanks for the write-up, you got most of the answers correct for your
> questions.
>
>
>
> Both lcptools and lcptools-v2 folders (in tboot source package) are for
> LCP V2 on TPM 1.2 platforms
>
>
>
> Folder lcp-gen2 is for LCP V3 creation on TPM 2.0 platform, so far tboot
> does not provide tpm 2.0 tools to write the LCP to TPM nv index, there are
> TPM 2.0 TSS and tools from Intel as well, see below.
>
>
>
> For tboot VLP, there is a default VLP in tboot source code, if there is no
> VLP found from TPM NV index, tboot will apply the default VLCP.
>
>
>
> For TPM 2.0 TSS and tools, here are the website for your reference:
>
>
>
> https://github.com/01org/TPM2.0-TSS
>
>
>
> https://github.com/01org/tpm2.0-tools
>
>
>
> -Ning
>
>
>
> *From:* Marco Vanotti [mailto:mvano...@google.com]
> *Sent:* Tuesday, May 23, 2017 1:32 PM
> *To:* tboot-devel@lists.sourceforge.net
> *Subject:* Re: [tboot-devel] Questions about Launch Control Policies
>
>
>
> Hi All!
>
>
>
> After reading a lot of documentation [*], I think I figured out the
> answers to some of the questions. I would like to confirm if what I think
> is correct.
>
>
>
> TBOOT sets up an environment and executes GETSEC[SENTER], which handles
> control over to the SINIT ACM. The SINIT ACM will measure the MLE and
> execute the policy engine, which validates the LCPs. The ACM will extend
> the MLE hash to PCR17 among other things.  After that, the ACM will handle
> control back to TBOOT, which will execute the post_launch mechanism. There,
> it will look for VLCPs, first in a special NV Index (0x0121 or
> 0x01c10131), or as a LCP_CUSTOM_ELEMENT in the policy data file, and then
> validates it.
>
>
>
> For remote attestation, you would want to get PCR17 and PCR18, maybe PCR0
> to make sure that BIOS is still the same? What I find unclear is how one
> should handle updates, BIOS, Kernel and TBOOT. It seems like the best way
> is to have a replicated setup for testing the updates and do all the
> measurements there.
>
>
>
> ---
>
>
>
> The problem with the NV Indices that I had (index 0x141 was being
> deleted on every reboot) was a BIOS issue. I contacted the platform
> supplier and asked for a BIOS update.
>
>
>
> The way to check which set of indices are used by your ACM is by checking
> the *tpm_nv_index_set* under the TPM capabilities in the loaded SINIT ACM
> (tables A-8 and A-9 from the intel txt guide, in Appendix A). The NVRAM
> Indices and attributes can be found in the Table J-2 (Appendix J TPM NV).
> For example, it says that the LCP PO index is 0x141 or 0x1c10106
> (depending on the tpm_nv_index_set).
>
>
>
> I have more questions, but I will try to write another email for them, as
> they are not related to this problem.
>
>
>
> Thank you all for your time :)
>
>
>
> Best Regards,
> Marco
>
>
>
> [*]:
>
> Intel TXT Software Development Guide: http://www.intel.com/co
> ntent/www/us/en/software-developers/intel-txt-software-devel
> opment-guide.html
>
> TPM 2.0 Spec: https://trustedcomputinggroup.org/tpm-library-specification/
>
> A practical guide to TPM 2.0: http://www.apress.com/us/book/9781430265832
>
> Intel Trusted Execution for Server Platfor

Re: [tboot-devel] Questions about Launch Control Policies

2017-05-23 Thread Sun, Ning 
Hi Marco,

Thanks for the write-up, you got most of the answers correct for your questions.

Both lcptools and lcptools-v2 folders (in tboot source package) are for LCP V2 
on TPM 1.2 platforms

Folder lcp-gen2 is for LCP V3 creation on TPM 2.0 platform, so far tboot does 
not provide tpm 2.0 tools to write the LCP to TPM nv index, there are TPM 2.0 
TSS and tools from Intel as well, see below.

For tboot VLP, there is a default VLP in tboot source code, if there is no VLP 
found from TPM NV index, tboot will apply the default VLCP.

For TPM 2.0 TSS and tools, here are the website for your reference:

https://github.com/01org/TPM2.0-TSS

https://github.com/01org/tpm2.0-tools

-Ning

From: Marco Vanotti [mailto:mvano...@google.com]
Sent: Tuesday, May 23, 2017 1:32 PM
To: tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] Questions about Launch Control Policies

Hi All!

After reading a lot of documentation [*], I think I figured out the answers to 
some of the questions. I would like to confirm if what I think is correct.

TBOOT sets up an environment and executes GETSEC[SENTER], which handles control 
over to the SINIT ACM. The SINIT ACM will measure the MLE and execute the 
policy engine, which validates the LCPs. The ACM will extend the MLE hash to 
PCR17 among other things.  After that, the ACM will handle control back to 
TBOOT, which will execute the post_launch mechanism. There, it will look for 
VLCPs, first in a special NV Index (0x0121 or 0x01c10131), or as a 
LCP_CUSTOM_ELEMENT in the policy data file, and then validates it.

For remote attestation, you would want to get PCR17 and PCR18, maybe PCR0 to 
make sure that BIOS is still the same? What I find unclear is how one should 
handle updates, BIOS, Kernel and TBOOT. It seems like the best way is to have a 
replicated setup for testing the updates and do all the measurements there.

---

The problem with the NV Indices that I had (index 0x141 was being deleted 
on every reboot) was a BIOS issue. I contacted the platform supplier and asked 
for a BIOS update.

The way to check which set of indices are used by your ACM is by checking the 
tpm_nv_index_set under the TPM capabilities in the loaded SINIT ACM (tables A-8 
and A-9 from the intel txt guide, in Appendix A). The NVRAM Indices and 
attributes can be found in the Table J-2 (Appendix J TPM NV). For example, it 
says that the LCP PO index is 0x141 or 0x1c10106 (depending on the 
tpm_nv_index_set).

I have more questions, but I will try to write another email for them, as they 
are not related to this problem.

Thank you all for your time :)

Best Regards,
Marco

[*]:
Intel TXT Software Development Guide: 
http://www.intel.com/content/www/us/en/software-developers/intel-txt-software-development-guide.html
TPM 2.0 Spec: https://trustedcomputinggroup.org/tpm-library-specification/
A practical guide to TPM 2.0: http://www.apress.com/us/book/9781430265832
Intel Trusted Execution for Server Platforms: 
http://www.apress.com/us/book/9781430261483
TPM 2.0 registry of reserved handles: 
https://trustedcomputinggroup.org/registry-reserved-tpm-2-0-handles-localities/

On Thu, May 4, 2017 at 7:19 PM, Marco Vanotti 
<mvano...@google.com<mailto:mvano...@google.com>> wrote:
Hi All!

I hope you are having a wonderful day today :). I am trying to get tboot to 
work in my machine. My computer has a TPM 2.0 and I am trying to understand 
some of the available features.

The Intel TXT Software Development Guide defines Launch Control Policies.  
Given that I have TPM 2.0, I believe I should use version 3.0 or 3.1, there 
seem to be some utilities to write these files in the lcp-gen2 folder.

Looking at the source code, I found that there's also TBOOT Control Policies, 
which seem to be referred as Verified Launch Control Policies. What is the 
difference between them? When should I use each of them? Are they also executed 
by the ACM? if not, when?

It seems that VLCPs don't support policy data files, is that so?

Regarding LCPs, where should I define them in NVRAM? I've tried using 
0x141, but that index gets deleted every time I reboot the system, 
regardless of using TXT. I'm defining the space with attr 0xF00F, and size 102 
bytes, which is the size of the lcp_policy_2 struct. There's another index to 
use that doesn't get deleted: 0x01c10106, but I am not sure how to tell TXT to 
use it.

My original goal was to install a policy with POLTYPE_ANY, just to test, but I 
can't see anything related to it in txt-stat, should it be logged somehow?

Any help with these issues would be really appreciated :)

Best Regards,
Marco

--
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.sou

Re: [tboot-devel] Questions about Launch Control Policies

2017-05-23 Thread Marco Vanotti 
Hi All!

After reading a lot of documentation [*], I think I figured out the answers
to some of the questions. I would like to confirm if what I think is
correct.

TBOOT sets up an environment and executes GETSEC[SENTER], which handles
control over to the SINIT ACM. The SINIT ACM will measure the MLE and
execute the policy engine, which validates the LCPs. The ACM will extend
the MLE hash to PCR17 among other things.  After that, the ACM will handle
control back to TBOOT, which will execute the post_launch mechanism. There,
it will look for VLCPs, first in a special NV Index (0x0121 or
0x01c10131), or as a LCP_CUSTOM_ELEMENT in the policy data file, and then
validates it.

For remote attestation, you would want to get PCR17 and PCR18, maybe PCR0
to make sure that BIOS is still the same? What I find unclear is how one
should handle updates, BIOS, Kernel and TBOOT. It seems like the best way
is to have a replicated setup for testing the updates and do all the
measurements there.

---

The problem with the NV Indices that I had (index 0x141 was being
deleted on every reboot) was a BIOS issue. I contacted the platform
supplier and asked for a BIOS update.

The way to check which set of indices are used by your ACM is by checking
the *tpm_nv_index_set* under the TPM capabilities in the loaded SINIT ACM
(tables A-8 and A-9 from the intel txt guide, in Appendix A). The NVRAM
Indices and attributes can be found in the Table J-2 (Appendix J TPM NV).
For example, it says that the LCP PO index is 0x141 or 0x1c10106
(depending on the tpm_nv_index_set).

I have more questions, but I will try to write another email for them, as
they are not related to this problem.

Thank you all for your time :)

Best Regards,
Marco

[*]:
Intel TXT Software Development Guide: http://www.intel.com/co
ntent/www/us/en/software-developers/intel-txt-software-devel
opment-guide.html
TPM 2.0 Spec: https://trustedcomputinggroup.org/tpm-library-specification/
A practical guide to TPM 2.0: http://www.apress.com/us/book/9781430265832
Intel Trusted Execution for Server Platforms: http://www.apress.c
om/us/book/9781430261483
TPM 2.0 registry of reserved handles: https://trustedcomputinggroup.org/
registry-reserved-tpm-2-0-handles-localities/

On Thu, May 4, 2017 at 7:19 PM, Marco Vanotti  wrote:

> Hi All!
>
> I hope you are having a wonderful day today :). I am trying to get tboot
> to work in my machine. My computer has a TPM 2.0 and I am trying to
> understand some of the available features.
>
> The Intel TXT Software Development Guide defines Launch Control Policies.
> Given that I have TPM 2.0, I believe I should use version 3.0 or 3.1, there
> seem to be some utilities to write these files in the lcp-gen2 folder.
>
> Looking at the source code, I found that there's also TBOOT Control
> Policies, which seem to be referred as Verified Launch Control Policies.
> What is the difference between them? When should I use each of them? Are
> they also executed by the ACM? if not, when?
>
> It seems that VLCPs don't support policy data files, is that so?
>
> Regarding LCPs, where should I define them in NVRAM? I've tried using
> 0x141, but that index gets deleted every time I reboot the system,
> regardless of using TXT. I'm defining the space with attr 0xF00F, and size
> 102 bytes, which is the size of the lcp_policy_2 struct. There's another
> index to use that doesn't get deleted: 0x01c10106, but I am not sure how to
> tell TXT to use it.
>
> My original goal was to install a policy with POLTYPE_ANY, just to test,
> but I can't see anything related to it in txt-stat, should it be logged
> somehow?
>
> Any help with these issues would be really appreciated :)
>
> Best Regards,
> Marco
>
--
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

[tboot-devel] Questions about Launch Control Policies

2017-05-04 Thread Marco Vanotti 
Hi All!

I hope you are having a wonderful day today :). I am trying to get tboot to
work in my machine. My computer has a TPM 2.0 and I am trying to understand
some of the available features.

The Intel TXT Software Development Guide defines Launch Control Policies.
Given that I have TPM 2.0, I believe I should use version 3.0 or 3.1, there
seem to be some utilities to write these files in the lcp-gen2 folder.

Looking at the source code, I found that there's also TBOOT Control
Policies, which seem to be referred as Verified Launch Control Policies.
What is the difference between them? When should I use each of them? Are
they also executed by the ACM? if not, when?

It seems that VLCPs don't support policy data files, is that so?

Regarding LCPs, where should I define them in NVRAM? I've tried using
0x141, but that index gets deleted every time I reboot the system,
regardless of using TXT. I'm defining the space with attr 0xF00F, and size
102 bytes, which is the size of the lcp_policy_2 struct. There's another
index to use that doesn't get deleted: 0x01c10106, but I am not sure how to
tell TXT to use it.

My original goal was to install a policy with POLTYPE_ANY, just to test,
but I can't see anything related to it in txt-stat, should it be logged
somehow?

Any help with these issues would be really appreciated :)

Best Regards,
Marco
--
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