On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen [off-list ref] wrote:

On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:

quoted

Hi Jarkko,

On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen [off-list ref] wrote:

quoted

On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:

quoted

From: Elaine Palmer <redacted>

Update trusted key documentation with additional comparisons between
discrete TPMs and TEE.

Signed-off-by: Elaine Palmer <redacted>

Right, so OP-TEE is not the same as TEE. I did not know this and the
patch set does not underline this.

I re-checked the patches and none of them say explicitly that OP-TEE
is an application living inside TEE.

This patch-set provides a trust source based on generic TEE interface
where underlying TEE implementations like OP-TEE (drivers/tee/optee/),
AMD TEE (drivers/tee/amdtee/) etc. can easily be hooked up. And this
is similar to the TPM interface where underlying TPM implementations
like discrete TPM, virtual TPM, firmware TPM etc. can be easily hooked
up.

quoted

This essentially means that the backend needs to be renamed as "op_tee".

I don't see any need for this, see above.

Right, TEE is a protocol standard, just like TPM, and OP-TEE is one
implementation of this interface? I.e. OP-TEE does not define API
that is hard bound to OP-TEE?

Yes, OP-TEE doesn't define a hard bound client interface API. The
client API is based on TEE client API specification [1] from
GlobalPlatform.

[1] http://globalplatform.org/specs-library/tee-client-api-specification/

-Sumit

Better to ask the very basic questions out and loud to get this
right.

/Jarkko