Hi I'm sorry for such a long delay!
On Fri, Jun 09, 2017 at 10:29:24AM -0400, Ken Goldman wrote: > At least a question, maybe a bug ... > > What is the expected behavior for the resource manager when it receives > contextsave for a transient object? > ] > ~~ > > Use case: > > Creating an RSA primary key can take a long time. I've seen it take 90 > seconds. The SRK will probably be made persistent. However, there are a > limited number of persistent object slots. So the less frequently used EK > will likely be created on demand. > > To improve performance, an application can context save the EK, and then > context load it when needed. This is a symmetric key operation, and is much > faster. This can work even for a new connection. > > ~~ > > When I try the command, write() returns 22, EINVAL > > The RM seems to have some special handling for context save in > tpm2_cmd.c:tpm2_get_cc_attrs_tbl(). Later, the write() returns EINVAL (22), It's done so that we do not need a special for it: treat it like it was part of the handle area. > probably because tpm2_map_command() does not find TPM2_CC_CONTEXT_SAVE in > the attribute table. > > ~~ > > Question: Is this expected? Is it the desired design? Nope but should never happen if there was TPMA_CC for ContextSave. > Bug: IMHO, EINVAL is a poor choice, as the application thinks the write() > failed. In fact, the TPM write() didn't even occur. Better would be to > construct the standard TPM response to an unimplemented command: > TPM_RC_COMMAND_CODE. This tells the application more accurately what failed > - the command code is not permitted. Not sure about this. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
