[tboot-devel] SENTER -> Legacy Shutdown

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello Joseph, tboot-devel (now that I know it exists :-),

I'm hoping for some advice debugging the invocation of GETSEC[SENTER]
after Linux has booted normally (without TBOOT).  We invoke SENTER from
a custom Linux kernel module.

Our system is a D3C6100 Software Development Platform, and we are able
to boot Xen with TBOOT successfully executing GETSEC[SENTER].  I.e., I
believe our hardware works and the relevant BIOS settings are correct.

When we invoke SENTER, the system appears to freeze.  The keyboard is
unresponsive and we are forced to reset the system (we've been using the
reset button on the motherboard).  Reading the LT.ERRORCODE register
during the next boot cycle yields: 0x80000000.  According to the
preliminary architecture specification (from August 2007: 31516804.pdf
(is there a newer version available?)) this is a processor-initiated
#LegacyShutdown.  From section 3.1, I gather that something caused a
triple-fault during the execution of SENTER.  Is this the correct
interpretation of a #LegacyShutdown?

We also tried some experiments with hopes of eliciting a richer failure
mode.  In the above experiment, TXTCR_SINIT_BASE is set to 0x7d500000
(we did not modify it; we only read this value), and we write the SINIT
module (BRLK_SINIT_20070910_debug.BIN) to precisely that physical
address.  Here is a summary of our additional experiments (note that
this is our code from within a Linux kernel module; the "TBOOT:"
prefixes are there because we stole shamelessly from TBOOT :):

(1) (precisely what I described above, for consistency)
use TXTCR_SINIT_BASE register as-is (0x7d500000)
set legitimate address of SINIT module (0x7d500000) as the argument of
__getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000000
TBOOT: processor error 0

Intel Trusted Execution Technology Preliminary Architecture
Specification on page 86, Table 23 says "Legacy shutdown".

In what follows, 0x00c00000 is an alternate physical address where we
position the SINIT module prior to executing SENTER.  0x00cc0000
(*different*) is an invalid address, in that it does _not_ contain an
SINIT module.

(2)
set TXTCR_SINIT_BASE register to invalid value (0x00cc0000)
set invalid address (0x00000000) as the argument of __getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000005
TBOOT: processor error 5

Intel Trusted Execution Technology Preliminary Architecture
Specification on page 86, Table 23 says "Load memory type error in
Authentication Code Execution Area".

(3)
set TXTCR_SINIT_BASE register to invalid value (0x00cc0000)
set legitimate address (0x7d500000) as the argument of __getsec_senter

Result:system does not freeze, it automatically reboots
TBOOT: LT.ERRORCODE=c0001841
TBOOT: AC module error : acm_type=1, progress=04, error=6
 --> SINIT region not completely contained within DPR

(4)
set TXTCR_SINIT_BASE register as 0x00c00000 (legitimate)
set legitimate address (0x00c00000) as the argument of __getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000005
TBOOT:   processor error 5

(5)
set TXTCR_SINIT_BASE register as 0x00c00000 (legitimate (yes, SINIT is
in 2 different places in memory))
set legitimate address (0x7d500000) as the argument of __getsec_senter

Result:system does not freeze, automatically reboot
TBOOT: LT.ERRORCODE=c0001841
TBOOT: AC module error : acm_type=1, progress=04, error=6
 --> SINIT region not completely contained within DPR

We also modified TBOOT to induce a failure, just to satisfy our
curiosity. If we intentionally set the page global directory to all 0s,
the error code changes to c0001071:
0100      one of the rules for table address ordering was not met.

I'm not sure what we're doing wrong wrt execution of SENTER.  The
Preliminary Architecture Specification does not provide enough detail to
be certain of every aspect of system configuration required for
successful launch.  For example, we are calling SENTER with CR0.PG=1
(Linux typically executes with paging enabled).  We disable the RLPs
(responding logical processors) using the cpu-hotplug facility in Linux,
which puts them into an acceptable state as far as I can tell.

I'm especially concerned about assumptions the processor and / or SINIT
module make with respect to the GDT before executing SENTER, and with
respect to the page tables pointed-to by MLE PageTableBase.  I think MLE
PageTableBase should be irrelevant until execution of SINIT is
almost-complete or totally completed.

Any suggestions or advice would be greatly appreciated.

Thanks,
-Jon