On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote: > > Hi Jarkko, > > > > On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > > > > > On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote: > > > > From: Elaine Palmer <erpalmer@xxxxxxxxxx> > > > > > > > > Update trusted key documentation with additional comparisons between > > > > discrete TPMs and TEE. > > > > > > > > Signed-off-by: Elaine Palmer <erpalmer@xxxxxxxxxx> > > > > > > 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. > > > > > > > > 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
