From: Sumit Garg <sumit.garg@linaro.org>
To: James Bottomley <jejb@linux.ibm.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Mimi Zohar <zohar@linux.ibm.com>,
dhowells@redhat.com, Jens Wiklander <jens.wiklander@linaro.org>,
Jonathan Corbet <corbet@lwn.net>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Janne Karhunen <janne.karhunen@gmail.com>,
Daniel Thompson <daniel.thompson@linaro.org>,
Markus Wamser <Markus.Wamser@mixed-mode.de>,
"open list:ASYMMETRIC KEYS" <keyrings@vger.kernel.org>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
op-tee@lists.trustedfirmware.org,
"tee-dev @ lists . linaro . org" <tee-dev@lists.linaro.org>
Subject: Re: [PATCH v5 0/4] Introduce TEE based Trusted Keys support
Date: Wed, 3 Jun 2020 13:37:44 +0530 [thread overview]
Message-ID: <CAFA6WYOoMdLJ2g3gocZBZWdu-7Nfw7LKHnzX8S8FKeC7cuNwYg@mail.gmail.com> (raw)
In-Reply-To: <1591108981.4253.17.camel@linux.ibm.com>
On Tue, 2 Jun 2020 at 20:14, James Bottomley <jejb@linux.ibm.com> wrote:
>
> On Tue, 2020-06-02 at 19:48 +0530, Sumit Garg wrote:
> > Add support for TEE based trusted keys where TEE provides the
> > functionality to seal and unseal trusted keys using hardware unique
> > key. Also, this is an alternative in case platform doesn't possess a
> > TPM device.
>
> So here's a meta problem: in the case when the platform possesses both
> TEE and TPM what should it do?
IMO, trust source (either a TPM or a TEE) should be unique and
carefully chosen as per platform security policy corresponding to a
particular threat model.
And moreover TEEs have been mostly used in the embedded world where
having a hardware TPM is cumbersome given constraints regarding BoM
cost and hardware resources.
> Things like this:
>
> > --- a/security/keys/trusted-keys/trusted_core.c
> > +++ b/security/keys/trusted-keys/trusted_core.c
> > @@ -25,6 +25,8 @@
> >
> > #if defined(CONFIG_TRUSTED_TPM)
> > static struct trusted_key_ops *trusted_key_ops =
> > &tpm_trusted_key_ops;
> > +#elif defined(CONFIG_TRUSTED_TEE)
> > +static struct trusted_key_ops *trusted_key_ops =
> > &tee_trusted_key_ops;
> > #else
>
> Say it's either/or at a Kconfig level: so if you select both TEE and
> TPM based trusted keys at compile time, we intall the TPM ops and
> ignore the TEE ops, is that right? Surely this should be runtime
> selectable based on what the platform has ...
This dynamic selection was already part of v4 patch-set but after
objection from Jarrko here [1], I switched to compile time mode
instead.
[1] https://lkml.org/lkml/2020/6/2/139
> perhaps it should even be
> selectable per key?
>
> Once it is runtime selectable, what should be selected in the both
> case? Or should we allow the user to decide, if so, how?
>
> when you pipe a trusted key, I think the subtype (TEE or TPM) should be
> part of the piped information, so it loads again seamlessly. This
> would actually be fixed by something like the ASN.1 scheme I'm trying
> to upstream, at least for TPM keys, but do TEE keys have a recognized
> ASN.1 format?
>
I guess this is something which we can refine later if there are real
platforms that have a particular security requirement to support both
TPM and a TEE.
-Sumit
> James
>
next prev parent reply other threads:[~2020-06-03 8:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-02 14:18 [PATCH v5 0/4] Introduce TEE based Trusted Keys support Sumit Garg
2020-06-02 14:18 ` [PATCH v5 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
2020-06-15 18:24 ` Jarkko Sakkinen
2020-06-16 13:32 ` Sumit Garg
2020-06-17 23:14 ` Jarkko Sakkinen
2020-06-18 6:42 ` Sumit Garg
2020-06-18 7:19 ` Jarkko Sakkinen
2020-06-02 14:18 ` [PATCH v5 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
2020-06-02 14:18 ` [PATCH v5 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
2020-06-02 14:18 ` [PATCH v5 4/4] MAINTAINERS: Add entry for TEE based Trusted Keys Sumit Garg
2020-06-02 14:43 ` [PATCH v5 0/4] Introduce TEE based Trusted Keys support James Bottomley
2020-06-03 8:07 ` Sumit Garg [this message]
[not found] ` <CAKrSGQSLKpb8T=H9zUoPP1B6EFrgMTMP3ZX1pEv99JtdPq7H0w@mail.gmail.com>
2020-06-03 11:45 ` Sumit Garg
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=CAFA6WYOoMdLJ2g3gocZBZWdu-7Nfw7LKHnzX8S8FKeC7cuNwYg@mail.gmail.com \
--to=sumit.garg@linaro.org \
--cc=Markus.Wamser@mixed-mode.de \
--cc=casey@schaufler-ca.com \
--cc=corbet@lwn.net \
--cc=daniel.thompson@linaro.org \
--cc=dhowells@redhat.com \
--cc=janne.karhunen@gmail.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jejb@linux.ibm.com \
--cc=jens.wiklander@linaro.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=op-tee@lists.trustedfirmware.org \
--cc=serge@hallyn.com \
--cc=tee-dev@lists.linaro.org \
--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).