** DO NOT MERGE** Improve TPM startup flow and nv enable

[dmcilvaney]

NvEnable() could be called multiple times without s_NVInitialized getting set to TRUE. An access conflict error would be generated, then ignored.

This should no longer happen.

Also improved handling of startup failure, and implemented the setjmp/longjmp calls.

[DMattoon]

This is by design. Apart from success/failure from NvEnable, a consumer of the platform API has no ability to receive/process error conditions (since these are platform-specific and the purpose of the platform API is to abstract away these details). Note also that the comment preceding NvEnable, and particularly the part describing the return value, is historical and it has never worked that way.

The consumer of the platform API may call NvEnable an arbitrary number of times before success is achieved. A return value of '0' indicates either recoverable failure (should retry) or that NV is already enabled. On the first successful call to NvEnable (and only the first successful call) a return value of '1' indicates success. Without first disabling NV, all subsequent calls to NvEnable will return '0'.

In the past the fTPM relied on this mechanism (for example, during boot there is a period during hand off from UEFI to Windows where storage is inaccessible yet the TPM must remain functional). But for trusted applications, there is no point in time where storage should be offline. We call NvEnable on entry point (re-)creation and failure is not tolerated.

Finally, while I don't have an issue with the other changes in this PR, the arguments and return values to/from platform routines that are visible to the TPM aren't something we control. If you would like to see the the success status for NvEnable adjusted, for example, I'll go talk to Andrey. That's not something we should change here since the platform API is a dependency of the TPM reference (even if the code and comments are not in agreement).

[dmcilvaney]

Based on discussion, consider this a proof of concept.