Re: [TrouSerS-users] Tspi_NV_ReleaseSpace ??

[Hal F. <hal...@gm...>]

On Thu, Dec 4, 2008 at 10:38 AM, Wyllys Ingersoll
<wyl...@su...> wrote:
> Thanks for the detailed response.
> What if no one has called DefineSpace with TPM_NV_INDEX_LOCK ?  If it is
> not locked, and the space was not created with owner auth, why can't I
> delete
> it (with or without the owner auth) ?  The situation is such that if I do
> not set
> the owner-auth, I get TPM_BAD_DATASIZE,if I do set owner-auth, I get
> "authentication failed".  It seems I am stuck and cannot clear this NV
> memory
> without resetting the TPM.

On my Infineon based system, where I have not locked the NV area, I
can delete NV space with owner auth. Now, in a quick test, Trousers
returned an error on this call. I did not have time to track down the
cause - possibly I had a bug in the test program. But even though
Trousers returned an error, subsequent runs showed that the space had
in fact been deleted.

Also, it is possible that some TPMs enforce the "D" bit even before
the NV space is locked:

"The 'D' bit indicates an NV index defined (typically) during
manufacturing and then locked. While nvLocked is FALSE, indices with
the 'D' set can be defined, deleted, or redefined as desired.  Once
nvLocked is set TRUE, the 'D' bit indices are locked.  They cannot be
defined, deleted or redefined." (TPM part 1, section 28.2)

The D bit is 0x10000000 in the index. (TPM part 2, section 19.1) So if
you are trying to delete space with this index bit set (which you
probably should not be doing) then it is possible that the TPM will
still reject that.

It's also possible that your owner auth value is wrong. Since many
TPMs appear to allow creation but not deletion without owner auth
while the NV area is unlocked, this might lead to the behavior you are
seeing.

Hal Finney