On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote: > 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 Thanks, bookmarked. No need for name change. /Jarkko
