Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

2016-09-02 Thread Brian E Luckau 
OK, it looks like we are at TPM 1.2.

TXT.ERRORCODE: 0xc00010c1

It is a XEON CPU E5 2660 v3 @ 2.60GHZ.  It looks like it loads the SINIT 
/ AC module loads from the BIOS.

As for chipset:  Intel Corporation C610/X99

How do you find the PS and AUX NVRAM index?

Also I am not implementing any policies, at least not on purpose.


On 09/02/2016 11:12 AM, Sun, Ning wrote:
> *Intel: https://github.com/01org/TPM2.0-TSS
> *TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools
> *IBM: http://sourceforge.net/projects/ibmtpm20tss/
>
>
> Regards,
> -NIng
>
> -Original Message-
> From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com]
> Sent: Friday, September 02, 2016 6:51 AM
> To: Brian E Luckau ; 'tboot-devel@lists.sourceforge.net' 
> 
> Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
>
> On Sep 1,  5:11pm, Brian E Luckau wrote:
> } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
>
>> Hi,
> Good morning Brian, I hope your day is starting out well.
>
> Also greetings to Safayet from GE who I see responded downthread as well.  I 
> will integrate his comments below.
>
>> Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or
>> CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly
>> and the last thing we see before the reboot is:
>>
>> TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2,
>> num_pages=32
>> TBOOT: The maximum allowed MTRR range size=256 Pages
>> TBOOT: executing GETSEC[SENTER]...
>>
>> In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS
>> is able to boot to completion.
>>
>> Is this a known issue?
> Welcome to SMX development and debugging... :-)
>
> As Safayet commented, the last line is the tboot hypervisor issueing the 
> SENTER leaf instruction to initiate execution of the Authenticated Code 
> Model.  Since the ACM is specifically designed to prevent it from being 
> debugged or examined, the only information available is if the ACM deigns to 
> place an errorcode in the TXT.ERRCODE SMX register.
>
> Unfortunately we are tracking a similar problem (ACM platform reset on
> GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which 
> gives one virtually nothing to go on.  It would be very helpful if you could 
> get the TXT.ERRCODE value for everyone to look at if it is other then zero, 
> if it is zero that would be a significant finding in and of itself.

> Secondly, could you provide a full description of the platform you are 
> attempting to implement your MLE on?  Hardware vendor, processor family 
> (Broadwell, Skylake, other et.al), chipset and whether or not the hardware 
> has a TPM1.2 or a TPM2 chip.  It would also be helpful to know the exact name 
> of the ACM module which you are loading.
>
> Thirdly, it would be helpful to know if you are implementing a Platform Owner 
> (PO) Launch Control Policy (LCP) and what version and type of the policy you 
> are implementing.  Based on our reading of the TXT/SDM, the lcp2_crtpol 
> utility provided with the tboot distribution is not capable of generating a 
> valid LCPv3 control policy if the ACM is processing it as we believe it 
> should be.
>
> If you would like to proceed forward independently on debugging this, check 
> to see whether the Platform Supplier (PS) and AUX NVRAM ind (PS) and AUX 
> NVRAM index
> ex locations are defined.  If you are on a TPM1.2 based system the PS index 
> should be at 0x5001 and the AUX will be at 0x5002 on platforms which 
> are Ivy Bridge and older and 0x5003 on platforms after that.  If you are 
> on a TPM2 based system we will be really interested in chatting with you.
>
> If you have PS and AUX registers defined, delete your PO NVram location and 
> try booting the system only with the PS and AUX indexes/registers.  I believe 
> the standard practice is for OEM board manufacturers to configure an ANY 
> policy in the PS index, which doesn't convey any practical security 
> guarantees but will usually result in a successful MLE.
>
> Just for the record we have been working for nine months to get a TXT/MLE 
> working on TPM2 based Broadwell platforms.  To spare everyone some anguish 
> there is no support for manipulating or managing TPM2 based NVram indexes in 
> the tboot package.  We built tooling on top of a library which we created 
> from the TSE utilities which Ken Goldman's lab at IBM has released.
>
> We are currently seeing the same system reset on GETSEC[SENTER] which Brian 
> is reporting.  The reset only occurs if a PO policy is supplied, which is 
> leading us to believe that the ACM processing of an LCPv3 PO policy is 
> flawed.  As I noted above the tboot utilities are not capable of producing a 
> valid policy, at least according to our read of the documentation.
>
>> --Brian Luckau
> I hope the above information is useful.  Be glad that you are not trying to 
> do SGX development as

Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

2016-09-02 Thread Sun, Ning 
*Intel: https://github.com/01org/TPM2.0-TSS
*TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools
*IBM: http://sourceforge.net/projects/ibmtpm20tss/


Regards,
-NIng

-Original Message-
From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] 
Sent: Friday, September 02, 2016 6:51 AM
To: Brian E Luckau ; 'tboot-devel@lists.sourceforge.net' 

Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

On Sep 1,  5:11pm, Brian E Luckau wrote:
} Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

> Hi,

Good morning Brian, I hope your day is starting out well.

Also greetings to Safayet from GE who I see responded downthread as well.  I 
will integrate his comments below.

> Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or 
> CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly 
> and the last thing we see before the reboot is:
>
> TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, 
> num_pages=32
> TBOOT: The maximum allowed MTRR range size=256 Pages
> TBOOT: executing GETSEC[SENTER]...
>
> In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS 
> is able to boot to completion.
>
> Is this a known issue?

Welcome to SMX development and debugging... :-)

As Safayet commented, the last line is the tboot hypervisor issueing the SENTER 
leaf instruction to initiate execution of the Authenticated Code Model.  Since 
the ACM is specifically designed to prevent it from being debugged or examined, 
the only information available is if the ACM deigns to place an errorcode in 
the TXT.ERRCODE SMX register.

Unfortunately we are tracking a similar problem (ACM platform reset on
GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which gives 
one virtually nothing to go on.  It would be very helpful if you could get the 
TXT.ERRCODE value for everyone to look at if it is other then zero, if it is 
zero that would be a significant finding in and of itself.

Secondly, could you provide a full description of the platform you are 
attempting to implement your MLE on?  Hardware vendor, processor family 
(Broadwell, Skylake, other et.al), chipset and whether or not the hardware has 
a TPM1.2 or a TPM2 chip.  It would also be helpful to know the exact name of 
the ACM module which you are loading.

Thirdly, it would be helpful to know if you are implementing a Platform Owner 
(PO) Launch Control Policy (LCP) and what version and type of the policy you 
are implementing.  Based on our reading of the TXT/SDM, the lcp2_crtpol utility 
provided with the tboot distribution is not capable of generating a valid LCPv3 
control policy if the ACM is processing it as we believe it should be.

If you would like to proceed forward independently on debugging this, check to 
see whether the Platform Supplier (PS) and AUX NVRAM index locations are 
defined.  If you are on a TPM1.2 based system the PS index should be at 
0x5001 and the AUX will be at 0x5002 on platforms which are Ivy Bridge 
and older and 0x5003 on platforms after that.  If you are on a TPM2 based 
system we will be really interested in chatting with you.

If you have PS and AUX registers defined, delete your PO NVram location and try 
booting the system only with the PS and AUX indexes/registers.  I believe the 
standard practice is for OEM board manufacturers to configure an ANY policy in 
the PS index, which doesn't convey any practical security guarantees but will 
usually result in a successful MLE.

Just for the record we have been working for nine months to get a TXT/MLE 
working on TPM2 based Broadwell platforms.  To spare everyone some anguish 
there is no support for manipulating or managing TPM2 based NVram indexes in 
the tboot package.  We built tooling on top of a library which we created from 
the TSE utilities which Ken Goldman's lab at IBM has released.

We are currently seeing the same system reset on GETSEC[SENTER] which Brian is 
reporting.  The reset only occurs if a PO policy is supplied, which is leading 
us to believe that the ACM processing of an LCPv3 PO policy is flawed.  As I 
noted above the tboot utilities are not capable of producing a valid policy, at 
least according to our read of the documentation.

> --Brian Luckau

I hope the above information is useful.  Be glad that you are not trying to do 
SGX development as that is a completely different can of worms :-)(

We will be interested in your findings.

Have a good holiday wekeend.

Greg

}-- End of excerpt from Brian E Luckau

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: g...@enjellic.com
--
"Those who will not study history are

Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

2016-09-02 Thread Dr. Greg Wettstein 
On Sep 1,  5:11pm, Brian E Luckau wrote:
} Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

> Hi,

Good morning Brian, I hope your day is starting out well.

Also greetings to Safayet from GE who I see responded downthread as
well.  I will integrate his comments below.

> Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or
> CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots
> constantly and the last thing we see before the reboot is:
>
> TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, num_pages=32
> TBOOT: The maximum allowed MTRR range size=256 Pages
> TBOOT: executing GETSEC[SENTER]...
>
> In centOS 7.2, if I disable Intel TXT in the BIOS then at least the
> OS is able to boot to completion.
>
> Is this a known issue?

Welcome to SMX development and debugging... :-)

As Safayet commented, the last line is the tboot hypervisor issueing
the SENTER leaf instruction to initiate execution of the Authenticated
Code Model.  Since the ACM is specifically designed to prevent it from
being debugged or examined, the only information available is if the
ACM deigns to place an errorcode in the TXT.ERRCODE SMX register.

Unfortunately we are tracking a similar problem (ACM platform reset on
GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated,
which gives one virtually nothing to go on.  It would be very helpful
if you could get the TXT.ERRCODE value for everyone to look at if it
is other then zero, if it is zero that would be a significant finding
in and of itself.

Secondly, could you provide a full description of the platform you are
attempting to implement your MLE on?  Hardware vendor, processor
family (Broadwell, Skylake, other et.al), chipset and whether or not
the hardware has a TPM1.2 or a TPM2 chip.  It would also be helpful to
know the exact name of the ACM module which you are loading.

Thirdly, it would be helpful to know if you are implementing a
Platform Owner (PO) Launch Control Policy (LCP) and what version and
type of the policy you are implementing.  Based on our reading of the
TXT/SDM, the lcp2_crtpol utility provided with the tboot distribution
is not capable of generating a valid LCPv3 control policy if the ACM
is processing it as we believe it should be.

If you would like to proceed forward independently on debugging this,
check to see whether the Platform Supplier (PS) and AUX NVRAM index
locations are defined.  If you are on a TPM1.2 based system the PS
index should be at 0x5001 and the AUX will be at 0x5002 on
platforms which are Ivy Bridge and older and 0x5003 on platforms
after that.  If you are on a TPM2 based system we will be really
interested in chatting with you.

If you have PS and AUX registers defined, delete your PO NVram
location and try booting the system only with the PS and AUX
indexes/registers.  I believe the standard practice is for OEM board
manufacturers to configure an ANY policy in the PS index, which
doesn't convey any practical security guarantees but will usually
result in a successful MLE.

Just for the record we have been working for nine months to get a
TXT/MLE working on TPM2 based Broadwell platforms.  To spare everyone
some anguish there is no support for manipulating or managing TPM2
based NVram indexes in the tboot package.  We built tooling on top of
a library which we created from the TSE utilities which Ken Goldman's
lab at IBM has released.

We are currently seeing the same system reset on GETSEC[SENTER] which
Brian is reporting.  The reset only occurs if a PO policy is supplied,
which is leading us to believe that the ACM processing of an LCPv3 PO
policy is flawed.  As I noted above the tboot utilities are not
capable of producing a valid policy, at least according to our read of
the documentation.

> --Brian Luckau

I hope the above information is useful.  Be glad that you are not
trying to do SGX development as that is a completely different can of
worms :-)(

We will be interested in your findings.

Have a good holiday wekeend.

Greg

}-- End of excerpt from Brian E Luckau

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: g...@enjellic.com
--
"Those who will not study history are doomed to debug it."
-- Barry Shein

-- 

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] reset after GETSEC[SENTER] on redhat platforms

2016-09-02 Thread Ahmed, Safayet (GE Global Research, US) 
If this is the last thing you see, there is likely an error being detected by 
the SINIT ACM module. To understand the cause of the error, take a look at the 
Intel TXT error register. There are many ways of doing this. The following is 
one way.

After the system reboots, boot into regular Linux (no TBoot, no Hypervisor). 
Assuming you installed the full TBoot package, you should have additional 
binaries installed, such as txt-stat and parse_err. Run parse_err and see what 
error code you get. Also, if you downloaded your SINIT ACM as a zip file from 
the Intel website, it should have come with an additional PDF document that 
tells you how to parse the 32-bit error value.

happy debugging,

Safayet

-Original Message-
From: Brian E Luckau [mailto:bluc...@sgi.com] 
Sent: Thursday, September 01, 2016 7:11 PM
To: 'tboot-devel@lists.sourceforge.net' 
Subject: EXT: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

Hi,

Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or CentOS 7.2, 
with Intel TXT enabled in the BIOS, it reboots constantly and the last thing we 
see before the reboot is:


TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, num_pages=32
TBOOT: The maximum allowed MTRR range size=256 Pages
TBOOT: executing GETSEC[SENTER]...

In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS is able 
to boot to completion.


Is this a known issue?

--Brian Luckau



--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tboot-2Ddevel=CwICAg=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg=31O_1ud4qXOENZh5xtrfQYA4v15IwXMivzk5SIQP0_4=cI322K4DrqyXtMEymn2b7uYfBaMYtZDN2Adm5me2wKU=
 

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel