On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote: > The intent of this "mostly transparent" stuff is to convey that the RM > should be as transparent as possible while acknowledging that there are > some cases where it's not / can't be. I can't say why the original > author phrased it in this somewhat ambiguous way but I wouldn't call > this a fair interpretation. It's definitely one way to read it though. > > The case in question is the RM performing a function on behalf of the > TPM: command code validation. This is a perfectly valid thing to do in > the RM though the RM should aim to behave as the TPM would if the RM > takes any action (sending a TPM response buffer with the appropriate > response code). > > An additional detail is described in section 3.1 "Error Codes". There is > a mechanism to encode information about which layer in the stack > produced the response buffer. When the TPM gets a command with a command > code it doesn't support then this field will be '0' since '0' identifies > the TPM. If the RM is taking over this function it should set the field > to indicate as much. Thanks for explaining this. I guess we could take this direction. I think by utilizing the field that you mentioned we could consider this. And it would be hard to imagine this change to cause anything serious (if anything at all) with backwards compatbility. Javier, does you current version use this field? If not can you resend an update? /Jarkko
