#184 trousers, tpm-tools incompatibility

[Charles Lohr]

I am on Debian 7, and attempted to take ownership of my TPM, but started running into internal software errors.

I opted to get a copy of trousers-trousers (3297fc) and trousers-tpm-tools (490afe6) from git. Cloned freshly. I did this based on the luck of those who built from CVS on the mailing lists of the past.

To make sure nothing hokey was going on with my system, I am running tcsd from the git folder:

src/tcsd/tcsd -f

and tpm_version from its respective git folder:

src/tpm_mgmt/tpm_version

When I run them, tcsd gets this:

TCSD svrside.c:556 accepted socket 8
TCSD svrside.c:531 Waiting for connections
TCSD tcsd_threads.c:233 total_recv_size 28, buf_size 1024, recd_so_far 28
TCSD tcsd_threads.c:285 Rx'd packet
TCSD TCS ERROR: rpc/tcstp/rpc.c:626 Invalid packet received by TCSD
LOG_RETERR TCSD TCS rpc/tcstp/rpc.c:627: 0x4
TCSD tcsd_threads.c:314 Sending 0x1C bytes back
TCSD TCS rpc/tcstp/rpc.c:68 Socket connection closed.
TCSD tcsd_threads.c:326 Thread exiting.

tpm_version gets this:

Tspi_Context_Create success
Tspi_Context_Connect failed: 0x00002004 - layer=tcs, code=0004 (4), Internal software error
Tspi_Context_FreeMemory success
Tspi_Context_Close success

uname -a: Linux u1000 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2+deb7u1 i686 GNU/Linux

Any ideas?

[Hon Ching(Vicky) Lo]

I got both trousers-trousers (3297fc) and trousers-tpm-tools (490afe6) from git. I can't replicate the problem. TCSD starts fine and tpm_version also gives expected result. But, I dont have a Debian system to test.

uname -a: Linux vtpm2014 2.6.32-358.11.1.el6.x86_64 #1 SMP Wed May 15 10:48:38 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux

[Charles Lohr]

I think the big difference between us is I'm stuck in 32-bit land.

I did some more digging though. I added some code to look at the packets in tcsd_threads.c and found that only the first two fileds are populated in the incoming packets.

It's just:

00 00 00 1c
00 00 00 01
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00

Which seems wrong, it fails the check to make sure the last few fields are properly populated.

After trying a different version of trousers, the packets work just fine. Though the problem appeared to me to be in the tpm-tools, the tpm-tools works with other tcsd's, so it unlikely to be that.

Can you think of anything else I could look at?

(P.S. The real problem for me right now is I can't find a working set of things to seal my TPM)

[Charles Lohr]

I just checked again. This time using tcpdump.

With the new trousers from Git, and trousers 0.3.13, I have the following interaction:

tpm_version: 0000 001c 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
tcsd: 0000 001c 0000 2004 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

(Error 0x2004)

In the debug output, it still says:

total_recv_size 28, buf_size 1024, recd_so_far 28
Rx'd packet
TCSD ERROR: rpc/tcstp/rpc.c:626 Invalid packet received by TCSD
TCSD TCS rpc/tcstp/rpc.c:627 0x04

If I use the old, CVS version I get the following interaction
tpm_version: 0000 001c 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
tcsd: 0000 0026 0000 0000 0000 0002 0000 0002 0000 001c 0000 0008 0000 001e 0303 a03b 2500 0000 0002

(And the chatter continues for a moment. All is well.)

TL;DR: I am having an issue specifically with trousers, not tpm-tools, and trousers 0.3.13, and current git 3297fc

[Charles Lohr]

Additionally, I've noticed that it is in fact parsing out the packet_size (28) and u.result (1) perfectly.

Problem is it is failing the check when it sees if the packet size == parm_offset + parm_size in tcstp/rpc.c:626.

Even more confusing, it seems to work if I scratch that check.

I'm still having other problems, but my scrutiny is placed on the check in rpc.c:626.

It should probably see if param_offset and size are zero, if so, I think the packet's still okay.

[Charles Lohr]

SOLUTION FOUND:

My system had a copy of libtspi installed which the tpm-tools were linking to. Because everything was over the TCP connection it masked the real problem.

Now, after uninstalling libtspi, things talk.