Re: [Trustedjava-support] TPM_NV_INDEX_TRIAL - wrong value

[Michael S. <ms...@nt...>]

After a long break, I'm finally getting back to this, and with a 
different set of TPMs.

I've got an STM TPM on my Lenovo T530 (as opposed to the intel one I had 
on the T510).  I've got an ATMEL TPM on a server machine with a TPM 
daughter card.

It turns out that the TPM daughter card with the ATMEL TPM does not have 
the nvLocked bit set.  I found this out when I was trying to use the 
TPM_NV_INDEX_TRIAL  index to check space availability, which instead 
ended up actually creating stuff.  I tried both the 0xf004 and 
0x1000f004 indexes and both ended up creating NV space.  I was easily 
able to delete the 0xf004 stuff, but I kept getting an error when I 
tried to delete the 0x1000f004 item.  This turned out to be a problem in 
/jTSS_0.7a/src/jtss_tsp/src/iaik/tc/tss/impl/java/tsp/TcNvRam.java 
around line 261. The code checks to see if you're trying to delete an 
index with the D bit set and throws an error, rather than attempting to 
do the delete and passing on the TPM originated error.

What I think you probably wanted to do here is do a try/catch block 
around the low-level call, and if there is an error, change the error 
cause message on the caught exception and continue the throw.  
Basically, explain the error if it happens, rather than anticipating it.

e.g.

try {
     TcTspInternal.TspNvDefineSpace_Internal(context_, pubData, encAuth, 
inAuth1, ownerAuth);
} catch (TcTssException ex) {
     if (ex.getErrCode() == TPM_E_BADINDEX) {
          if ((nvIndex_ & TcTssConstants.TSS_NV_DEFINED) != 0) {
                 ex.setMessage("index with set-defined bit is not allowed");
           }
     }
     throw ex;
}

I know there isn't a setMessage method for TcTssException, but you 
should either have that or the normal exception "new 
<exception>(Throwable cause)" constructor.

For my work around, I commented out the block and was able to delete 
both rogue indexes.



The second problem I encountered was in the same code.  I attempted to 
lock the NVRam by defining space of size 0 at index 0xffffffff so I 
wouldn't encounter further problems. Unfortunately, that failed with a 
Null pointer error which I traced to line 88 of TcNvRam.  You pass in a 
null pointer for the iAuth argument and later routines blow up because 
of it.    I haven't yet tried the simple work around of commenting out 
this "if" block, but it's probable that 
TcTspInternal.TspNvDefineSpace_Internal needs some revision to catch 
null arguments and handle them properly.


Thanks - Mike





On 7/9/2012 10:55 AM, Michael Gissing wrote:
> On 05/14/2012 07:31 PM, Michael StJohns wrote:
>> Hi --
>
> Hi Michael,
>
>> For some reason, TcTpmConstants.TPM_NV_INDEX_TRIAL has the "D" bit
>> set.    This is probably a bug.
>
> I agree that this is not the best value for this constant. It will be 
> changed to 0x0000f004 in a future release. Anyhow please note that 
> it's a valid index according to the specification.
>
>> I used the constant in TcINvRam.defineSpace (in TcTpmNvData) to see if I
>> had space to create a 100 octet space.  What I ended up with was a
>> permanent 100 octet space that I can't get rid of.
>
> What exactly do you mean by 'can't get rid of'? According to the TPM 
> specification this should not happen. When you try to define an index 
> with the D-bit set, a shipped TPM should return TPM_BADINDEX. Which 
> TPM do you use? Is the TPM's nvLocked bit set to true? If it is not, 
> then D-bit indices can be defined, but also deleted.
>
> Can you please provide the output of the following commands?
>
> jtt tpm_version
> jtt tpm_flags
> jtt nv_decode --index 0x1000f004
>
>> When I use the correct value - 0xF004 - as the index, I get the
>> anticipated behavior.  A "success" results in a return with no creation.
>
> That's what I would have expected ;)
>
>> I'd review all of the TPM_NV_INDEX_* values and make sure you're using
>> the correct values.
>
> Both versions with and without D-bit set are correct. For 
> compatibility reasons the other constants will remain unchanged.
>
>> Mike
>
> HTH,
> Michael