On 11/26/2017 03:18 PM, Jarkko Sakkinen wrote: > 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? > My current version wasn't setting the error level bits. I'll send a new version that does this. I'll also drop the RFC prefix and propose it as a formal patch since it seems we are getting closer to an agreement and also add James as cc. > /Jarkko > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat
