On 11/17/2017 11:57 AM, Jason Gunthorpe wrote:
On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
This patch is an RFC because I'm not sure if this is the correct way to fix this
issue. I'm not that familiar with the TPM driver so may had missed some details.
And example of user-space getting confused by the TPM chardev returning -EINVAL
when sending a not supported TPM command can be seen in this tpm2-tools issue:
https://github.com/intel/tpm2-tools/issues/621
I think this is a user space bug, unfortunately.
We talked about this when the spaces code was first written and it
seemed the best was to just return EINVAL to indicate that the kernel
could not accept the request.
This result is semantically different from the TPM could not execute
or complete the request.
I think there is a difference between:
- The kernel could __not__ accept the request, and
- The kernel could accept the request, but there's code in the kernel to
reject it.
My preference is for the kernel to send the command when possible, and
let the TPM decide whether it can be executed.
Otherwise, the kernel device driver has to be updated every time the TPM
implements something new that the kernel previously thought was an error.
