On 9/17/2014 12:40 PM, Bill Martin wrote: > Just a followup > > Make sure as some folks have said on the Trousers Users list > discussion that your nvLock is defined. I think I ruined a TPM chip > by setting the lock wrong.
It should not be possible to ruin a TPM by setting the lock. All the lock means is that you need authorization to use NV. You can use ownerAuth to undefine NV, and you can use ForceClear if you forget the ownerAuth. The one slight exception is an index with the D bit set. These can be defined and deleted while NV is not locked. Once locked, these indexes cannot be defined or erased. So, if you did this: - received an unlocked TPM NV (should never happen) - defined NV space with the D bit set - locked the TPM NV then the indexes are permanent. The TPM is not ruined, but you've consumed some or all the NV space. The use case for the D bit is the manufacturer EK certificate. > /usr/local/sbin/tpm_nvdefine -i 0xFFFFFFFF --size=0 > > The size is critical. I defined a size of 100 on my other TPM chip > and could not go back. The locking of PCRs did not work at all. According to the spec, the lock must work if the size is zero. If the size is not zero, it may lock or it may return an error, but it should not break anything. So, if you tried a lock with size 100, the TPM might have returned TPM_BADINDEX and not locked. Then locking NV to PCRs won't work - yet. However, you should still be able to lock the chip by setting the size to 0. It's not like you only get one chance. ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ TrouSerS-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-users
