Re: [tboot-devel] tboot + TPM 2.0 + TXT (boot with grub2)

[Marco Vanotti via tboot-devel]

Hi Xiao, Greg,

Adding to what Greg said, I would start by loading a POLTYPE_ANY and then
checking the Event log from txt-stat to see if the policy has been read.
After that, go ahead and use the gen2 tools to create the policies.

Keep in mind that the logs you sent are not about the LCP but about the
Verified LCP (tboot specific ones, checked the Policy Engine verifies
everything). You will get more LCP information from the TPM Event Log.
Also, check the error codes after each failed boot.

Basically the steps I did to make sure everything was working were:

- Launch without any LCP.
- Launch with a VLCP, modifying the default one (manually)
- Launch with a LCP POLTYPE_ANY. (created manually or by gen2 tools)
- Launch with an LCP that checks the MLE (created by gen2 tools)

At each experiment check the TPM Event Log (from txt-stat). I could not
find a hardware that was working correctly out of the shelf, not even Intel
NUC's.

Best Regards,
Marco

On Thu, Jul 13, 2017 at 6:01 AM, Dr. Greg Wettstein 
wrote:

> On Wed, Jul 12, 2017 at 06:01:02PM -0700, Xiao Li wrote:
>
> > Hi,
> >
> > Wish everyone has a good day.
>
> Hi Xiao, I hope this note finds you day and week going well.
>
> > I have been trying to use tpm2-tools and tboot to setup LCP policy
> > for my platform using TPM 2.0. I have successfully done it with
> > tboot provided nvdef and nvwrite with a TPM 1.2 chip on the same
> > host. However when it comes to TPM2.0 my setup never succeeds.
>
> Launch Control Policies on TXT/TPM2 are a bit of a problem.  We have
> poured a ton of time into resolving functionality issues with only
> limited success.
>
> First of all it would be helpful to know what hardware platform you
> are using as different platforms have different issues associated with
> them.  Depending on what the platform OEM has decided to do it may not
> even be possible to use TXT/TBOOT even if the processor and chipset
> technically support it.
>
> I'm assuming since you are using 0x204000A for the NVram attributes
> that this is a post-Broadwell platform?
>
> In addition what version of tboot are you using?  I see that they have
> the 1.9.6 up on Sourceforge.  If you are experimenting with TPM2 based
> systems you will want to be running that since earlier versions had no
> hope of working on TPM2 based hardware.
>
> > I have tried to use nvindex:
> > #0x01C10131
> > #0x01C10106
> > #0x0141
> > they all behaved a bit different from each other, but all seem like tboot
> > failed to load launch control policy:
>
> The NVram index locations which should be used are defined by the ACM
> module you are using, which is in turn defined by your hardware
> platform.
>
> After you get the most recent release of the tboot package run the
> 'acminfo' command on your ACM module and look for the following in the
> output:
>
>  TPM info list:
>  TPM capability:
>   ext_policy: 0x3
>   tpm_family : 0x3
>   tpm_nv_index_set : 0x0
>
> The 'tpm_nv_index_set' value specifies the NVram index locations which
> will be used.  If it is 0x0 you will need to use the 'old' values, ie
> the 0x141 for the PO policy.
>
> We have not personally seen any hardware in the wild which is using
> the 'new' values.
>
> > My first attempt was using the following commands:
> >
> > tpm2_takeownership -o new -e new -l new
> > tpm2_nvdefine -x 0x01C10106 -a 0x4001 -s 70 -t 0x204000A -P new
> > lcp2_mlehash --verbose --create --alg sha256 --cmdline
> > "logging=serial,memory,vga extpol=sha256" /boot/tboot.gz > mle_hash
> > lcp2_crtpolelt --verbose --create --type mle --alg sha256 --ctrl 0x00
> > --minver 0 --out tbootmle.elt mle_hash
> > lcp2_crtpollist --verbose --create --out list_unsig.lst tbootmle.elt
> > lcp2_crtpol --verbose --create --type list --pol list.pol --alg sha256
> > --data list.data list_unsig.lst
> > tpm2_nvwrite -x 0x01C10106 -a 0x4001 -f list.pol -P new
>
> The lcp2_* tools will not create valid policies for TPM2 systems.  At
> a minimum they are not encoding valid hash function selector
> attributes into the policy files.
>
> I believe that the python based tools in the lcp-gen2 directory are
> the only hope for getting valid policy files.  Those are cumbersom so
> we are fiddling in our spare time trying to get the C based utilities
> to work properly.
>
> > Thanks in advance,
> > Xiao Li
>
> Hopefully the above information will get you started.
>
> If you report back to the list answer the questions above on what
> hardware you are using since that will be important in making further
> progress.
>
> Good luck wih your efforts and have a good remainder of the week.
>
> Greg
>
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.   Specializing in information infra-structure
> Fargo, ND  58102development.
> PH: 701-281-1686
> FAX: 701-281-3949   EMAIL: 

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

[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

[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] "Invalid RSDP" TXT Error

[Marco Vanotti]

Hi All,

I still couldn't fix the issue. However, there was a problem with the
policies I used (the ones I created myself). I created another policy, with
the lcp-gen2 tools and tried them in another machine with the same MLE.

I was able to get a successful boot in the other machine, but not in the
NUC. I still get the same error "Invalid RSDP"

Reading the tboot source code, tboot/txt/txt.c is where the rdsp is set up:

http://hg.code.sf.net/p/tboot/code/file/f1d2d60eda9f/tboot/txt/txt.c#l557

/* capabilities : require MLE pagetable in ECX on launch */
/* TODO: when SINIT ready
 * os_sinit_data->capabilities.ecx_pgtbl = 1;
 */
os_sinit_data->capabilities.ecx_pgtbl = 0;
if (is_loader_launch_efi(lctx)){
/* we were launched EFI, set efi_rsdt_ptr */
struct acpi_rsdp *rsdp = get_rsdp(lctx);
if (rsdp != NULL){
if (version < 6){
/* rsdt */
/* NOTE: Winston Wang says this doesn't work for v5 */
os_sinit_data->efi_rsdt_ptr = (uint64_t) rsdp->rsdp1.rsdt;
} else {
/* rsdp */
memcpy((void *)_rsdp, rsdp, sizeof(struct acpi_rsdp));
os_sinit_data->efi_rsdt_ptr = (uint64_t)((uint32_t)_rsdp);
}
} else {
/* per discussions--if we don't have an ACPI pointer, die */
printk(TBOOT_ERR"Failed to find RSDP for EFI launch\n");
return NULL;
}
}


It says that "this doesn't work for v5", my sinit is v5. So maybe it is
related? Do I need a newer sinit?


---

Here are the policies I am using:


$ xxd mle.pol
: 0003 0b00        
0010:    0800   0800 0800  
0020:  0800  7505 ed2f c309 bd31 fc8e  ..u../...1..
0030: 544c ec55 1030 4e88 8457 2460 11e4 394f  TL.U.0N..W$`..9O
0040: b612 bc3a fbec   ...:..

$ xxd mle.data
: 496e 7465 6c28 5229 2054 5854 204c 4350  Intel(R) TXT LCP
0010: 5f50 4f4c 4943 595f 4441 5441    _POLICY_DATA
0020:  0001 0002 1000 3200  3200   2...2...
0030: 1000     0b00 0100 abc0  
0040: 5dd2 0aae d8bc ab2f 3dc1 7512 e9b5 f3b7  ]../=.u.
0050: 55da 3ab0 e62c 553d 45c8 4cd3 44f0   U.:..,U=E.L.D.


On Tue, May 23, 2017 at 9:59 PM, Marco Vanotti <mvano...@google.com> wrote:

> Hi All!
>
> I am trying to get TXT working. I was able to get it to run with
> POLTYPE_ANY, however, as soon as I added a policy data file, I started
> getting *TXT error 0xC00020C1*, which for  my SINIT ACM means "*Invalid
> RSDP*". (note that this error doesn't happen if I don't add the policy
> data module in grub2).
>
> Specific details about my setup:
>
> * Intel NUC NUC5i5MYHE
> * TPM 2.0
> * PO NV Index: 0x141, with attributes 0x4000A:
> - TPMA_NV_OWNERWRITE
> - TPMA_NV_POLICYWRITE
> - TPMA_NV_AUTHREAD
> * "5th_gen_i5_i7_SINIT_79.BIN" SINIT ACM, downloaded from intel website.
> It seems to be "version 5"
> * Latest BIOS Update (couple of weeks old).
>
>
> This issue seems to have been discussed in this list previously (
> https://sourceforge.net/p/tboot/mailman/message/35623784/ is one message
> of that mailing thread), but it seems that they couldn't find a solution.
>
> Any help debugging this problem would be really appreciated :)
>
> Best Regards,
> Marco
>
> --
> --
>
> (details about Grub2 and Policies that I am using)
>
> This is my grub2 config related to tboot:
>
> menuentry 'CentOS Linux GNU/Linux, with tboot 1.9.4 and Linux
> 3.10.0-514.16.1.el7.x86_64' --class centos --class gnu-linux --class gnu
> --class os --class tboot {
> insmod multiboot2
> insmod part_gpt
> insmod xfs
> set root='hd0,gpt2'
> if [ x$feature_platform_search_hint = xy ]; then
>  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
> --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  dd1f25a9-de82-4943-8ba9-
> f3a5035678a2
> else
>  search --no-floppy --fs-uuid --set=root dd1f25a9-de82-4943-8ba9-
> f3a5035678a2
> fi
> echo 'Loading tboot 1.9.4 ...'
> multiboot2 /tboot.gz logging=serial,memory extpol=sha256
> echo 'Loading Linux 3.10.0-514.16.1.el7.x86_64 ...'
> module2 /vmlinuz-3.10.0-514.16.1.el7.x86_64 root=/dev/mapper/cl_txtnuc-root
> ro crashkernel=auto rd.lvm.lv=cl_txtnuc/root rd.lvm.lv=cl_txtnuc/swap
> rhgb quiet intel_iommu=on noefi
> echo 'Loading initial ramdisk ...'
> module2 /initramfs-3.10.0-514.16.1.el7.

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

[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

[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

[tboot-devel] "Invalid RSDP" TXT Error

[Marco Vanotti]

Hi All!

I am trying to get TXT working. I was able to get it to run with
POLTYPE_ANY, however, as soon as I added a policy data file, I started
getting *TXT error 0xC00020C1*, which for  my SINIT ACM means "*Invalid
RSDP*". (note that this error doesn't happen if I don't add the policy data
module in grub2).

Specific details about my setup:

* Intel NUC NUC5i5MYHE
* TPM 2.0
* PO NV Index: 0x141, with attributes 0x4000A:
- TPMA_NV_OWNERWRITE
- TPMA_NV_POLICYWRITE
- TPMA_NV_AUTHREAD
* "5th_gen_i5_i7_SINIT_79.BIN" SINIT ACM, downloaded from intel website. It
seems to be "version 5"
* Latest BIOS Update (couple of weeks old).


This issue seems to have been discussed in this list previously (
https://sourceforge.net/p/tboot/mailman/message/35623784/ is one message of
that mailing thread), but it seems that they couldn't find a solution.

Any help debugging this problem would be really appreciated :)

Best Regards,
Marco

--
--

(details about Grub2 and Policies that I am using)

This is my grub2 config related to tboot:

menuentry 'CentOS Linux GNU/Linux, with tboot 1.9.4 and Linux
3.10.0-514.16.1.el7.x86_64' --class centos --class gnu-linux --class gnu
--class os --class tboot {
insmod multiboot2
insmod part_gpt
insmod xfs
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
 dd1f25a9-de82-4943-8ba9-f3a5035678a2
else
 search --no-floppy --fs-uuid --set=root
dd1f25a9-de82-4943-8ba9-f3a5035678a2
fi
echo 'Loading tboot 1.9.4 ...'
multiboot2 /tboot.gz logging=serial,memory extpol=sha256
echo 'Loading Linux 3.10.0-514.16.1.el7.x86_64 ...'
module2 /vmlinuz-3.10.0-514.16.1.el7.x86_64 root=/dev/mapper/cl_txtnuc-root
ro crashkernel=auto rd.lvm.lv=cl_txtnuc/root rd.lvm.lv=cl_txtnuc/swap rhgb
quiet intel_iommu=on noefi
echo 'Loading initial ramdisk ...'
module2 /initramfs-3.10.0-514.16.1.el7.x86_64.img
echo 'Loading sinit 5th_gen_i5_i7_SINIT_79.BIN ...'
module2 /5th_gen_i5_i7_SINIT_79.BIN
echo 'Loading tboot policy data file lcp.data ...'
module2 /lcp.data
}

I have tried creating a Policy with the lcp-gen2 files, as well as creating
my own. In both cases it did not work. What follows is the policy I am
using, with explanation of each field.


policy.pol, written to TPM Index 0x141, size 102 bytes.

xxd policy.pol
000: 0003 0b00 0001       
010:    0400   0800 0800  
020:    3f1f 5a59 07d4 3b1e 0ef3  ..?.ZY..;...
030: 2cda 07fe 0c7a 9c58 be39 a03e b6af d88d  ,z.X.9.>
040: 8b9c b92e 6355       cU..
050:          
060:      ..

Description:

Policy Version: 3.0 (0x0003)
Hash Algorithm: TPM_ALG_SHA256 (0x000B),
Policy Type: LCP_POLTYPE_LIST (0x00),
SINIT Min Version: 1 (0x01)
Data Revocation Counters: 0x 8 times.
Policy Control: Only set "OS Sinit Data Capabilities" (0x 0004)
Max SINIT min version: 255 (0xff)
Max BIOS AC min version: 255 (0xff)
Approved Hash Alg Mask: Only SHA256 (0x0008)
Approved Sign Alg Mask: tpm_alg_rsassa_2048_sha256 (0x 0008)
Aux Hash Alg Mask: None. (0x)
Reserved (2 bytes) (0x)
Policy Hash: SHA256(SHA256(Policy List)). The rest of the bytes are because
it is an union.

policy.data, saved to /boot/lcp.data, 126 bytes.

xxd tmp.data
: 496e 7465 6c28 5229 2054 5854 204c 4350  Intel(R) TXT LCP
0010: 5f50 4f4c 4943 595f 4441 5441    _POLICY_DATA
0020:  0001 0102 1000 5200  5200   R...R...
0030: 1000  0100   0b00 0100 abc0  
0040: 5dd2 0aae d8bc ab2f 3dc1 7512 e9b5 f3b7  ]../=.u.
0050: 55da 3ab0 e62c 553d 45c8 4cd3 44f0   U.:..,U=E.L.D...
0060:          
0070:          ..

File Signature: LCP_POLICY_DATA_FILE_SIGNATURE (32 bytes)
Reserved (3 bytes) (0x00)
Num Lists: 1 (0x01)

[From here starts the LCP_POLICY_LIST2]
Version: 2.1 (0x0201)
Signature Algorithm: TPM_ALG_NULL (0x0010)
Policy Element Size: 82 bytes (0x 0052)
[From here starts the LCP_POLICY_ELEMENT]
Size: 82 bytes (0x 0052)

Type: LCP_POLELT_TYPE_MLE2 (0x 0010)
Policy Element Control: DEFAULT_POL_ELT_CONTROL (0x 0001)
[From here starts the LCP_MLE_ELEMENT2]
SINIT Min Version: 0 (0x0)
Reserved (1 byte) (0x0)
Hash Algorithm: SHA256 (0x000b)
Num Hashes: 1 (0x0001)
Hashes: SHA256 of MLE as reported by TPM 2.0 Event Log.

The hash of the LCP_LIST
is 983f986b1e16fbee53be445a8f040ea1669bf52280ae8ebf768caf05bb77e33f
SHA256(983f986b1e16fbee53be445a8f040ea1669bf52280ae8ebf768caf05bb77e33f)
= 3f1f5a5907d43b1e0ef32cda07fe0c7a9c58be39a03eb6afd88d8b9cb92e6355

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

[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 <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.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] Questions about Launch Control Policies

[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