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.
This patch-set has been tested with OP-TEE based early TA which is already
merged in upstream [1].
[1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d…
Changes in v8:
1. Added static calls support instead of indirect calls.
2. Documented trusted keys source module parameter.
3. Refined patch #1 commit message discription.
4. Addressed misc. comments on patch #2.
5. Added myself as Trusted Keys co-maintainer instead.
6. Rebased to latest tpmdd master.
Changes in v7:
1. Added a trusted.source module parameter in order to enforce user's
choice in case a particular platform posses both TPM and TEE.
2. Refine commit description for patch #1.
Changes in v6:
1. Revert back to dynamic detection of trust source.
2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
3. Rebased to latest tpmdd/master.
Changes in v5:
1. Drop dynamic detection of trust source and use compile time flags
instead.
2. Rename trusted_common.c -> trusted_core.c.
3. Rename callback: cleanup() -> exit().
4. Drop "tk" acronym.
5. Other misc. comments.
6. Added review tags for patch #3 and #4.
Changes in v4:
1. Pushed independent TEE features separately:
- Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
2. Updated trusted-encrypted doc with TEE as a new trust source.
3. Rebased onto latest tpmdd/master.
Changes in v3:
1. Update patch #2 to support registration of multiple kernel pages.
2. Incoporate dependency patch #4 in this patch-set:
https://patchwork.kernel.org/patch/11091435/
Changes in v2:
1. Add reviewed-by tags for patch #1 and #2.
2. Incorporate comments from Jens for patch #3.
3. Switch to use generic trusted keys framework.
Sumit Garg (4):
KEYS: trusted: Add generic trusted keys framework
KEYS: trusted: Introduce TEE based Trusted Keys
doc: trusted-encrypted: updates with TEE as a new trust source
MAINTAINERS: Add myself as Trusted Keys co-maintainer
Documentation/admin-guide/kernel-parameters.txt | 12 +
Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++--
MAINTAINERS | 2 +
include/keys/trusted-type.h | 47 +++
include/keys/trusted_tee.h | 55 ++++
include/keys/trusted_tpm.h | 17 +-
security/keys/trusted-keys/Makefile | 2 +
security/keys/trusted-keys/trusted_core.c | 354 ++++++++++++++++++++++
security/keys/trusted-keys/trusted_tee.c | 278 +++++++++++++++++
security/keys/trusted-keys/trusted_tpm1.c | 336 ++++----------------
10 files changed, 979 insertions(+), 327 deletions(-)
create mode 100644 include/keys/trusted_tee.h
create mode 100644 security/keys/trusted-keys/trusted_core.c
create mode 100644 security/keys/trusted-keys/trusted_tee.c
--
2.7.4
struct tee_param: revc -> recv.
TEE_IOC_SUPPL_SEND: typo introduced by copy-pasting, replace invalid
description with description from the according argument struct.
Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru>
---
include/linux/tee_drv.h | 2 +-
include/uapi/linux/tee.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
index d074302989dd..61557bc0e29f 100644
--- a/include/linux/tee_drv.h
+++ b/include/linux/tee_drv.h
@@ -85,7 +85,7 @@ struct tee_param {
* @close_session: close a session
* @invoke_func: invoke a trusted function
* @cancel_req: request cancel of an ongoing invoke or open
- * @supp_revc: called for supplicant to get a command
+ * @supp_recv: called for supplicant to get a command
* @supp_send: called for supplicant to send a response
* @shm_register: register shared memory buffer in TEE
* @shm_unregister: unregister shared memory buffer in TEE
diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
index b619f37ee03e..7546be5ed4f8 100644
--- a/include/uapi/linux/tee.h
+++ b/include/uapi/linux/tee.h
@@ -342,7 +342,7 @@ struct tee_iocl_supp_send_arg {
};
/**
- * TEE_IOC_SUPPL_SEND - Receive a request for a supplicant function
+ * TEE_IOC_SUPPL_SEND - Send a response to a received request
*
* Takes a struct tee_ioctl_buf_data which contains a struct
* tee_iocl_supp_send_arg followed by any array of struct tee_param
--
2.28.0
Use flexible-array member introduced in C99 instead of zero-length
array. Most of zero-length array was already taken care in previous
patch [1]. Now modified few more cases which were not handled earlier.
[1]. https://patchwork.kernel.org/patch/11394197/
Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com>
---
drivers/tee/optee/optee_msg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
index 7b2d919..b1f1e90 100644
--- a/drivers/tee/optee/optee_msg.h
+++ b/drivers/tee/optee/optee_msg.h
@@ -199,7 +199,7 @@ struct optee_msg_arg {
u32 num_params;
/* num_params tells the actual number of element in params */
- struct optee_msg_param params[0];
+ struct optee_msg_param params[];
};
/**
--
2.7.4
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.12.0 is scheduled to be released at 2021-01-15. So, now is
a good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/4291.
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related to
releases here: https://optee.readthedocs.io/en/latest/general/releases.html
Regards,
Joakim
Hi Robert,
Comments below.
On Mon, Dec 28, 2020 at 7:49 PM Robert Delien via OP-TEE
<op-tee(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> As discussed earlier, our application requires secured display contents and
> is using a secure frame buffer.
>
> Now to transit from U-Boot to Op-tee as smoothly as possible, I would like
> to copy the contents from the U-Boot frame buffer into the Optee frame
> buffer upon LCD driver initialisation.
>
> The U-Boot frame buffer address is calculated at run time and I haven't
> found a hand-off mechanism, but the physical address can be easily read
> from the LCDIF peripheral's registers. Unfortunately, no MMU mapping is
> present per default for this physical address outside the TZDRAM area.
>
> Is it possible to temporarily map this rather arbitrary non-secure physical
> DDR address outside TZDRAM, so I can access it through a virtual address?
> Preferably in a way that I can also remove this mapping after copying the
> frame buffer?
Yes, it's actually easier than one might first imagine. I assume you
will interact with OP-TEE via a Pseudo TA. This framebuffer is normal
non-secure DDR from OP-TEE point of view, so it should be possible to
just supply it as a memref parameter when invoking the PTA.
Cheers,
Jens
Hi,
As discussed earlier, our application requires secured display contents and
is using a secure frame buffer.
Now to transit from U-Boot to Op-tee as smoothly as possible, I would like
to copy the contents from the U-Boot frame buffer into the Optee frame
buffer upon LCD driver initialisation.
The U-Boot frame buffer address is calculated at run time and I haven't
found a hand-off mechanism, but the physical address can be easily read
from the LCDIF peripheral's registers. Unfortunately, no MMU mapping is
present per default for this physical address outside the TZDRAM area.
Is it possible to temporarily map this rather arbitrary non-secure physical
DDR address outside TZDRAM, so I can access it through a virtual address?
Preferably in a way that I can also remove this mapping after copying the
frame buffer?
Thanks in advance; Your help is highly appreciated.
With kind regards,
Robert.
--
DISCLAIMER
De informatie, verzonden in of met dit e-mailbericht, is
vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het gebruik
van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging,
verspreiding en|of verstrekking daarvan aan derden is niet toegestaan.
Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt
verboden. Aan deze informatie kunnen geen rechten worden ontleend. U wordt
verzocht bij onjuiste adressering de afzender direct te informeren door het
bericht te retourneren en het bericht uit uw computersysteem te verwijderen.
On Tue, 22 Dec 2020 08:50:56 +0000
Vesa Jääskeläinen via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> On 2020-10-08 08:53, Jens Wiklander wrote:
> > Hi Sumit,
> >
> > On Wed, Oct 7, 2020 at 11:27 AM Sumit Garg <sumit.garg(a)linaro.org> wrote:
> >>
> >> Hi Jens,
> >>
> >> On Thu, 17 Sep 2020 at 19:10, Sumit Garg <sumit.garg(a)linaro.org> wrote:
> >>>
> >>> Since the addition of session's client UUID generation via commit [1],
> >>> login via REE kernel method was disallowed. So fix that via passing
> >>> nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well.
> >>>
> >>> Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") [1]
> >>> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org>
> >>> ---
> >>> drivers/tee/tee_core.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>
> >> Would you like to pick up this fix?
> >
> > Thanks for the reminder.
> > This looks good to me. I'll pick up this unless someone objects.
> > Vesa, does this look good to you too?
> >
> > Cheers,
> > Jens
>
> Sorry I have been away for a while from the mailing list.
>
> It seems that this is merged -- only thing that came to my mind with
> this is that:
>
> If we have some kernel protected keys or so -- should we have separate
> client UUID for kernel operations.
>
> Like when TEE_IOCTL_LOGIN_REE_KERNEL is given then client UUID would be
> generated for "kernel".
>
> This way we can make sure that kernel owned keys stays for kernel. Nil
> UUID is kinda reserved for public login.
Isn't this unnecessary? According to the TEE Internal Core API Specification,
TEE_Identity, a data type that "defines the full identity of a Client", consists
of a UUID *and* one of the TEE_LOGIN_XXX constants. Therefore, TEE_LOGIN_PUBLIC
with a nil UUID is a different client than TEE_LOGIN_REE_KERNEL with a nil UUID.
> Thanks,
> Vesa Jääskeläinen
>
> >
> >>
> >> -Sumit
> >>
> >>> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> >>> index 64637e0..2f6199e 100644
> >>> --- a/drivers/tee/tee_core.c
> >>> +++ b/drivers/tee/tee_core.c
> >>> @@ -200,7 +200,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method,
> >>> int name_len;
> >>> int rc;
> >>>
> >>> - if (connection_method == TEE_IOCTL_LOGIN_PUBLIC) {
> >>> + if (connection_method == TEE_IOCTL_LOGIN_PUBLIC ||
> >>> + connection_method == TEE_IOCTL_LOGIN_REE_KERNEL) {
> >>> /* Nil UUID to be passed to TEE environment */
> >>> uuid_copy(uuid, &uuid_null);
> >>> return 0;
> >>> --
> >>> 2.7.4
> >>>
>
Since the addition of session's client UUID generation via commit [1],
login via REE kernel method was disallowed. So fix that via passing
nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well.
Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") [1]
Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org>
---
drivers/tee/tee_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index 64637e0..2f6199e 100644
--- a/drivers/tee/tee_core.c
+++ b/drivers/tee/tee_core.c
@@ -200,7 +200,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method,
int name_len;
int rc;
- if (connection_method == TEE_IOCTL_LOGIN_PUBLIC) {
+ if (connection_method == TEE_IOCTL_LOGIN_PUBLIC ||
+ connection_method == TEE_IOCTL_LOGIN_REE_KERNEL) {
/* Nil UUID to be passed to TEE environment */
uuid_copy(uuid, &uuid_null);
return 0;
--
2.7.4