NvFile assertion check fails after upgrading tpm2-tss to v4.1.3

[krabinowitz1]

Hi libtpms maintainers — I realize this behavior originates in tpm2-tss rather than libtpms itself, but I’m hoping to get your guidance since libtpms is the layer being affected and the maintainers of tpm2-tss have not been engaging with recent issues.

We're using libtpms via the tpm2-tss tcti-libtpms API. After upgrading to v4.1.3, our application crashes when it calls the API to open a connection to the simulated TPM. This assertion in libtpms is failing because it expects the NvFile to exist, but our application, which runs inside a Linux Docker container as a non-root user, is lacking necessary permissions to create said file.

When we used v4.0.1 of tpm2-tss, we did not encounter this problem because of the registered callbacks being implemented for tpm_nvram_loaddata and tpm_nvram_storedata. But this commit set these callbacks to NULL, which changes the behavior of libtpms to its use its default implementation, as your docs explain.

It's not exactly clear to me why this change to remove the callbacks was needed. The commit title mentions something about PCR overwrites, but that's as much context as I have on that.

One additional point I wanted to sanity-check relates to documented behavior versus what we’re observing in practice.

The tpm2-tss documentation for tcti-libtpms currently states:

If no state file is passed via conf, all state is held in RAM and discarded when the process dies.

But when using v4.1.3 that doesn’t appear to be true anymore. If no state file is explicitly passed via tpm2-tss configuration, libtpms appears to fall back to its default persistence mechanism, which writes TPM state to a file via its internal implementation.

From an integration standpoint, this is surprising, because it effectively changes the default behavior from ephemeral in-memory state to file-backed persistence, even when the caller does not opt into persistence.

Our use case is intentionally narrow. We only require the library's functionality for MakeCredential and signature verification (VerifySignature), and to the best of our understanding these operations do not depend on persistent TPM state such as PCR allocation, NV indices, or other long-lived configuration.

Because of this, we’d prefer an option to be able to retain the previous behavior — i.e., a true in-RAM-only mode — so that we don’t need to grant filesystem permissions or risk file-update contention in high-traffic environments when it wouldn't provide any tangible benefits for our scenario. If there is no way around it, however, what would be the recommended approach?

[stefanberger]

We're using libtpms via the tpm2-tss tcti-libtpms API. After upgrading to v4.1.3, our application crashes when it calls the API to open a connection to the simulated TPM. This assertion in libtpms is failing because it expects the NvFile to exist, but our application, which runs inside a Linux Docker container as a non-root user, is lacking necessary permissions to create said file.

The assert has been in libtpms since forever basically, so it's not like it wasn't writing to a file at all when it couldn't open a file for writing.

When we used v0.9.6 of tpm2-tss, we did not encounter this problem because of the registered callbacks being implemented for tpm_nvram_loaddata and tpm_nvram_storedata. But this commit set these callbacks to NULL, which changes the behavior of libtpms to its use its default implementation, as your docs explain.

I don't think it has anything to do with v0.9.6 in particular, but this would have happened with all versions of libtpms.

That they removed the callbacks is the actual problem. The man page kind of points out that this should not be used with a NULL pointer and I would urge the authors to restore the callbacks.
From the man page:

"If this function is not set (NULL), then the original NVChip file will be read when using a TPM 2. This file contains the memory dump of internal data structures and is neither portable between endianesses or architectures of different sizes (32 bit, 64 bit), nor will it allow handling extensions of those internal data structures it carries through additions in the TPM 2 code. In the worst case this may result in memory access errors by internal functions and result in crashes. Therefore, it is recommended to set this function and handle the writing of the TPM state."

It's not exactly clear to me why this change to remove the callbacks was needed. The commit title mentions something about PCR overwrites, but that's as much context as I have on that.

If there are issues due to the callbacks I think they should talk to me.

One additional point I wanted to sanity-check relates to documented behavior versus what we’re observing in practice.

The tpm2-tss documentation for tcti-libtpms currently states:

If no state file is passed via conf, all state is held in RAM and discarded when the process dies.

I do not know what this means 'when no state file is passed'. Maybe that was related to the callback, because the way it works with the NULL pointers is that the hardcode NVChip file is being used.

But when using v4.1.3 that doesn’t appear to be true anymore. If no state file is explicitly passed via tpm2-tss configuration, libtpms appears to fall back to its default persistence mechanism, which writes TPM state to a file via its internal implementation.

They should not be changing the behavior of their implementation...

From an integration standpoint, this is surprising, because it effectively changes the default behavior from ephemeral in-memory state to file-backed persistence, even when the caller does not opt into persistence.

Our use case is intentionally narrow. We only require the library's functionality for MakeCredential and signature verification (VerifySignature), and to the best of our understanding these operations do not depend on persistent TPM state such as PCR allocation, NV indices, or other long-lived configuration.

Because of this, we’d prefer an option to be able to retain the previous behavior — i.e., a true in-RAM-only mode — so that we don’t need to grant filesystem permissions or risk file-update contention in high-traffic environments when it wouldn't provide any tangible benefits for our scenario. If there is no way around it, however, what would be the recommended approach?

I think you should talk to them about restoring the original behavior.

[krabinowitz1]

Hey Stefan, thanks for getting back to this during the holidays.

The assert has been in libtpms since forever basically, so it's not like it wasn't writing to a file at all when it couldn't open a file for writing.

yes but that assert line was not getting hit previously, nor was the file ever getting created, because the tpm_nvram_loaddata callback was being set before by tpm2-tss. When set, _plat__NVEnable returns early and never calls _plat__NVEnable_NVChipFile which is where the file gets created and the assertion is.

I don't think it has anything to do with v0.9.6 in particular, but this would have happened with all versions of libtpms.

Agreed. I accidentally used the libtpms version number to refer to the tpm2-tss version. I meant to type 4.0.1 there.

If there are issues due to the callbacks I think they should talk to me.

That would be great. Unfortunately it doesn't look like that repo is actively being looked at. At least not the issues. I can try submitting a PR to restore the original behavior, and maybe reference this issue so that they have context on the why.