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=0x7bf00000, size=0x20000, 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 0x50000001 and the AUX will be at 0x50000002 on
platforms which are Ivy Bridge and older and 0x50000003 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 58102 development.
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
