Hi Joanna,

On Fri, Aug 31, 2012 at 5:47 AM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> So, am I asking a wrong question? ;)

I can try to give an answer to a related question...

> On 08/09/12 20:19, Joanna Rutkowska wrote:
>> I'm curious whether activation of the JTAG interface affects PCR values,
>> be that those measured as part of SRTM, or those as part of
>> SENTER/SINIT?

I got started with dynamic root of trust on AMD hardware.  Let me
relate some details for AMD, and then I will talk about Intel.  I had
access to one of AMD's Hardware Debug Tools (HDT) at the time.  To the
best of my knowledge, this device connects directly to some CPU pins
(via a motherboard header that breaks them out).

>From AMD manual 24596 ("System Programming"), Rev 3.20, December 2011:
Section 15.27.6: "Debug Considerations: SKINIT automatically disables
various implementation-specific hardware debug features. A debug
version of the SL can reenable those features by clearing the
VM_CR.DPD flag immediately upon entry."

I empirically determined that, indeed, the HDT is useless in the
interval between executing SKINIT and having an instruction in the
launched code to clear VM_CR.DPD.

On Intel, we did not have any direct debugger device support from
Intel.  We did have an Intel Software Development Platform (SDP) which
is a machine that takes a special debug-signed SINIT module.  I ended
up purchasing an "interposer" which is literally a CPU socket that
plugs into another CPU socket and accepts the actual CPU.  I think the
vendor was InterTestTech, and it was for an LGA 775 socket.  A fancy
ribbon cable sticks out the side that can connect to a hardware
debugger.  The debugger that I had access to was an American Arium
ECM-50.  It required another active adapter board to convert between
the interface on the ECM-50 and the interface of the Interposer.  I
have no idea whether the actual protocol is JTAG or not.  I think the
proper term might be In-Circuit Emulator ("ICE").  I have no idea if
it was Intel-specific or a more general protocol.

Both the debugger hardware itself and the software that allows one to
operate it were from before the introduction of TXT.  Thus, there was
no access to TXT-related MSRs or other CPU-internal state.  Trying to
single step through SENTER always seemed to wedge the debugger in some
bad state, iirc.  However, I never had any trouble using that debugger
to isolate non-TXT related problems (e.g., invalid segment descriptors
in the GDT) very soon after having invoked SENTER.  Now, because the
machine where I installed this required a special debug SINIT module,
I really have no idea whether that use of a debug SINIT module puts
the system in a state where a hardware debug tool can be effective, or
whether Intel's TXT design doesn't directly address this.  To my
knowledge, the debug SINIT is identical to the non-debug SINIT, but is
signed by a different keypair.  Again, I have no idea if that impacts
the system's attack surface with respect to hardware debug tools.
These interposers and debuggers were too expensive for me to just buy
a few and experiment with it.

I cannot recall anything from any manual, book, or specification that
speaks to this issue for Intel platforms.  That does not mean that one
doesn't exist somewhere.

>> Or perhaps SENTER/SINIT aborts if JTAG is enabled (which
>> would be actually pretty reasonable)?

On the one system where I have experience, there were no aborts.  The
SINIT measurement should reflect that a debug-signed SINIT module was
used, however.

Hope this helps, and please do keep up the good work,
-Jon

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Reply via email to