Thread (13 messages) 13 messages, 4 authors, 2021-01-20

Re: [PATCH] doc: trusted-encrypted: updates with TEE as a new trust source (update)

From: Jarkko Sakkinen <jarkko@kernel.org>
Date: 2021-01-20 14:28:01

On Wed, Jan 20, 2021 at 04:21:54PM +0200, Jarkko Sakkinen wrote:
On Fri, Jan 15, 2021 at 06:15:51PM -0500, Elaine Palmer wrote:
quoted

On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:
quoted
On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
quoted
On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen [off-list ref] wrote:
quoted
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
Thanks, bookmarked. No need for name change. /Jarkko
This discussion has illustrated that even those of us who live and
breathe this stuff could use clarification.  Shouldn't we recommend
that the Trust Source have a hardware root of trust?  We could be
even more specific.  For example, the documentation could recommend
that a TPM be evaluated under "TCG Protection Profile for PC Client
Specific TPM 2.0" or later and a TEE be evaluated under GlobalPlatform
"TEE Protection Profile v1.3, GPD_SPE_021" or later.  Of course, our
recommendation would not be a requirement, but it would provide
guidance for deployment as well as precedent for future Trust Sources.
Recommend what? Not following. I don't undestand what recommending
trust sources means, and why it's written as Trust Sources.
I don't even understand what "evaluating TPM" means. Does not sound
like anything that belongs to the kernel documentation.

/Jarkko
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help