From: Sumit Garg <sumit.garg@linaro.org>
To: Elaine Palmer <erpalmerny@gmail.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
Mimi Zohar <zohar@linux.ibm.com>,
linux-integrity@vger.kernel.org,
Elaine Palmer <erpalmer@us.ibm.com>,
George Wilson <gcwilson@us.ibm.com>,
zgu@us.ibm.com
Subject: Re: [PATCH] doc: trusted-encrypted: updates with TEE as a new trust source (update)
Date: Mon, 18 Jan 2021 12:23:37 +0530 [thread overview]
Message-ID: <CAFA6WYP5zQOk-C47L9se6V2zJmtq8rCha1SL-kgr_dRxQSM=sA@mail.gmail.com> (raw)
In-Reply-To: <19d3547b-c285-aa98-0cc3-cc55ef09a1b9@gmail.com>
Hi Elaine,
On Sat, 16 Jan 2021 at 04:45, Elaine Palmer <erpalmerny@gmail.com> wrote:
>
>
>
> On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:
> > On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
> >> On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@kernel.org> 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@kernel.org> wrote:
> >>>>> On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> >>>>>> From: Elaine Palmer <erpalmer@us.ibm.com> Update trusted key
> >>>>>> documentation with additional comparisons between discrete TPMs
> >>>>>> and TEE. Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> >>>>> 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
> 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.
>
Sure, I will update documentation to mention this as a recommendation.
> I know where I'm getting stuck is on TEEs as a concept vs
> TEEs with specific hardware requirements and interfaces.
> The same applies to TPMs. There are hardware TPMs that meet
> the protection profile and there are other implementations
> (e.g., vTPMs) that use the same interface, but aren't anchored in
> hardware.
Similar is the case with TEEs which can have varying hardware
realizations. Have a look at "Figure 2-3: Example Hardware
Realizations of TEE" from TEE system architecture specification [1].
[1] https://globalplatform.org/specs-library/tee-system-architecture-v1-2/
>
> I know if I were deploying a server, mobile device, or IoT device, I'd
> want to know exactly what is protecting my keys. A generic TPM or TEE
> doesn't tell me enough.
>
Agree.
-Sumit
> -Elaine
>
>
next prev parent reply other threads:[~2021-01-18 6:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 16:42 [PATCH] doc: trusted-encrypted: updates with TEE as a new trust source (update) Mimi Zohar
2020-12-11 8:14 ` Jarkko Sakkinen
2020-12-11 15:16 ` Mimi Zohar
2021-01-04 12:36 ` Sumit Garg
2021-01-10 3:16 ` Jarkko Sakkinen
2021-01-12 5:25 ` Sumit Garg
2021-01-13 21:23 ` Jarkko Sakkinen
2021-01-15 23:15 ` Elaine Palmer
2021-01-18 6:53 ` Sumit Garg [this message]
2021-01-20 14:21 ` Jarkko Sakkinen
2021-01-20 14:25 ` Jarkko Sakkinen
2021-01-04 12:15 ` Sumit Garg
2021-01-10 3:14 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFA6WYP5zQOk-C47L9se6V2zJmtq8rCha1SL-kgr_dRxQSM=sA@mail.gmail.com' \
--to=sumit.garg@linaro.org \
--cc=erpalmer@us.ibm.com \
--cc=erpalmerny@gmail.com \
--cc=gcwilson@us.ibm.com \
--cc=jarkko@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=zgu@us.ibm.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).