Remove transient object from TPM after context-saving

[AndreasFuchsTPM]

IMHO, it would be good practice for the tools to remove transient objects from the TPM after they were saved and stored to disk. Since the kernel as well as the user-space resource managers will do so anyways, the functional flow will not change. On the opposite, this will allow tools to be used without a resource manager on a TPM or simulator directly.

IMHO even better would be, to conditionally save and flush transient object, only if a context output file was provided and leave them inside the TPM if none was provided.

From my analysis, this should be the easiest of fixes, by adding something like

if ((handle & TPM2_HR_RANGE_MASK) == TPM2_HR_TRANSIENT) {
    TSS2_RC rval = Esys_FlushContext(ectx, handle);
    if (rval != TPM2_RC_SUCCESS) {
        LOG_PERR(Eys_ContextFlush, rval);
        return false;
}

after https://github.com/tpm2-software/tpm2-tools/blob/6163942372cd9da7ed6687730d0d814ded56df1b/lib/files.c#L218-L222

@williamcroberts Would you agree with either of the approaches ? Shall I send the PR ?

[idesai]

@AndreasFuchsSIT

1. Agree with flushing the transient object from TPM when saved to the disk. Question is does the resource manager try to keep track of such a handle that has been explicitly flushed by the application. Would it then: a. Attempt to flush the handle again b. Flush the handle# without realizing it was re-allocated to another application

2. IIUC this would mean making the output context optional in tools like load, createload, loadexternal. This approach would work only when a resource manager is not in play. Leaving any in the TPM would be categorically flushed by the resource manager.

[AndreasFuchsTPM]

1. If something was flushed by the application, the RM sees that and seizes tracking that object; aka will not flush.
2. Yes. The intention was, if we want to somehow keep the current capability of the tools to create transient object inside the TPM if no RM is around. The reason being that I don't know, if people are relying on this feature. In that case, we don't want to take it away. But I cannot really say, whether it is being used.

Alternatively to 2., we could introduce a "--don't-flush" option.

[idesai]

Agreed. Another approach could be since tools know the TCTI it is talking to and can process missing command line option for the context file, i guess we could do something like: if tcti!=RM and !tool.cmdline.contextfile <don't flush> All other cases following a contextsave of the transient object we always flush.

[AndreasFuchsTPM]

One question though: Currently, if !tool.cmdline.contextfile then the tool will auto-select a filename and store stuff, see https://github.com/tpm2-software/tpm2-tools/blob/6163942372cd9da7ed6687730d0d814ded56df1b/tools/tpm2_createprimary.c#L135-L137 So the question is, whether this is old and/or desired behavior of the tools and if we can just alter it ?

[idesai]

One question though: Currently, if !tool.cmdline.contextfile then the tool will auto-select a filename and store stuff, see

https://github.com/tpm2-software/tpm2-tools/blob/6163942372cd9da7ed6687730d0d814ded56df1b/tools/tpm2_createprimary.c#L135-L137

So the question is, whether this is old and/or desired behavior of the tools and if we can just alter it ?

Not sure why it was introduced. May be there was a reason but IMHO I'd prefer dropping this existing behavior of creating files with default filenames in favor of what's been discussed here since the later has more functional impact.

[AndreasFuchsTPM]

Ok, cool. I'll start working on some code and wait for @williamcroberts to also agree.

[williamcroberts]

One question though: Currently, if !tool.cmdline.contextfile then the tool will auto-select a filename and store stuff, see https://github.com/tpm2-software/tpm2-tools/blob/6163942372cd9da7ed6687730d0d814ded56df1b/tools/tpm2_createprimary.c#L135-L137

So the question is, whether this is old and/or desired behavior of the tools and if we can just alter it ?

That needs to die, IIRC their is a bug for this. Supposedly I fixed this: https://github.com/tpm2-software/tpm2-tools/issues/1457 (I don't trust that for some reason though).

I have no problems with flushing transient handles on context save

[AndreasFuchsTPM]

Ok, so the final question is: What's the desired behavior if no output-filename is provided: a) Keep transient b) Complain I assume it's (b) but just wanted to make sure

[williamcroberts]

Ok, so the final question is: What's the desired behavior if no output-filename is provided: a) Keep transient b) Complain I assume it's (b) but just wanted to make sure

Yeas B, the user should always specify or we complain.

[idesai]

Add --auto-flush to tools and an environment variable "export TPM2_TOOLS_AUTOFLUSH=true|false" could resolve this. We don't want to make the default behavior to flush, as that can break scripts and workflows.

[tomoveu]

Having an extra environment variable for autoflush would solve a lot of pain. +1 for "export TPM2_TOOLS_AUTOFLUSH=true|false". What is the current plan for this feature? @idesai

[JuergenReppSIT]

I will add the option (-R, --autoflush) for all the commands which call context save for transient objects., and check the environment variable in tpm2_context_save. @AndreasFuchsTPM @idesai I would say we should also flush the parent object if -R is used e.g. for: tpm2_create -C primary.ctx -u key.pub -r key.priv -c key.ctx -Tdevice:/dev/tpm0 -R ?

[idesai]

@JuergenReppSIT If there is a need to create multiple objects then I'd have to load the parent each time. Although, I can see why it can also be useful to leave the TPM in a state prior to executing the command. So perhaps: -R for flushing (1) Sessions used in the most recent command -RR for flushing (1) Sessions and (2) Key-objects used in the most recent command -RRR for flushing all (1) Sessions, (2) Key-objects and (3)Sequence-handles from most recent command -RRRR for flushing all (1) Sessions, (2) Key-objects and (3) Sequence-handles from all previous commands essentially rendering the TPM in a clean state.