From: Allen Pais <apais(a)linux.microsoft.com>
The following out of memory errors are seen on kexec reboot
from the optee core.
[ 0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed
[ 0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22
tee_shm_release() is not invoked on dma shm buffer.
Implement .shutdown() in optee core as well as bnxt firmware driver
to handle the release of the buffers correctly.
More info:
https://github.com/OP-TEE/optee_os/issues/3637
v2:
keep the .shutdown() method simple. [Jens Wiklander]
Allen Pais (2):
optee: fix tee out of memory failure seen during kexec reboot
firmware: tee_bnxt: implement shutdown method to handle kexec reboots
drivers/firmware/broadcom/tee_bnxt_fw.c | 9 +++++++++
drivers/tee/optee/core.c | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.25.1
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 v9:
1. Rebased to latest tpmdd/master.
2. Defined pr_fmt() and removed redundant tags.
3. Patch #2: incorporated misc. comments.
4. Patch #3: incorporated doc changes from Elaine and misc. comments
from Randy.
5. Patch #4: reverted to separate maintainer entry as per request from
Jarkko.
6. Added Jarkko's Tested-by: tag on patch #2.
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 entry for TEE based Trusted Keys
.../admin-guide/kernel-parameters.txt | 12 +
.../security/keys/trusted-encrypted.rst | 171 ++++++--
MAINTAINERS | 8 +
include/keys/trusted-type.h | 53 +++
include/keys/trusted_tee.h | 16 +
include/keys/trusted_tpm.h | 29 +-
security/keys/trusted-keys/Makefile | 2 +
security/keys/trusted-keys/trusted_core.c | 358 +++++++++++++++++
security/keys/trusted-keys/trusted_tee.c | 317 +++++++++++++++
security/keys/trusted-keys/trusted_tpm1.c | 366 ++++--------------
10 files changed, 981 insertions(+), 351 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.25.1
If build kernel without "O=dir", below error will be seen:
In file included from drivers/tee/optee/optee_trace.h:67,
from drivers/tee/optee/call.c:18:
./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such file or directory
95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
| ^
compilation terminated.
Fix it by adding below line to Makefile:
CFLAGS_call.o := -I$(src)
Tested with and without "O=dir", both can build successfully.
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Suggested-by: Steven Rostedt <rostedt(a)goodmis.org>
Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com>
---
drivers/tee/optee/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
index 56263ae3b1d7..3aa33ea9e6a6 100644
--- a/drivers/tee/optee/Makefile
+++ b/drivers/tee/optee/Makefile
@@ -6,3 +6,6 @@ optee-objs += rpc.o
optee-objs += supp.o
optee-objs += shm_pool.o
optee-objs += device.o
+
+# for tracing framework to find optee_trace.h
+CFLAGS_call.o := -I$(src)
--
2.31.0
Hello arm-soc maintainers,
Please pull this small patch for the OP-TEE driver to remove the invalid
size check of outgoing memref parameters. This code path is only
activated for a certain configuration of OP-TEE in secure world
(CFG_CORE_DYN_SHM=n) so this problem isn't always visible.
Thanks,
Jens
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-memref-size-for-v5.13
for you to fetch changes up to c650b8dc7a7910eb25af0aac1720f778b29e679d:
tee: optee: do not check memref size on return from Secure World (2021-03-30 10:44:50 +0200)
----------------------------------------------------------------
OP-TEE skip check of returned memref size
----------------------------------------------------------------
Jerome Forissier (1):
tee: optee: do not check memref size on return from Secure World
drivers/tee/optee/core.c | 10 ----------
1 file changed, 10 deletions(-)
Hello arm-soc maintainers,
The previous pull request for OP-TEE tracepoints introduced a build
error when building whithout O=..., apparently many regression builds
uses that option.
Please pull this small fix for the build error.
Thanks,
Jens
The following changes since commit 0101947dbcc3204f08fb5b69a21dbd4b1535cad6:
tee: optee: add invoke_fn tracepoints (2021-03-15 12:04:01 +0100)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-tracepoints-fix-for-v5.13
for you to fetch changes up to 7ccdcaace80810175bd20b2ece856b42edd43991:
tee: optee: fix build error caused by recent optee tracepoints feature (2021-03-30 09:33:33 +0200)
----------------------------------------------------------------
Fixes build error for recently added OP-TEE tracepoints
----------------------------------------------------------------
Jisheng Zhang (1):
tee: optee: fix build error caused by recent optee tracepoints feature
drivers/tee/optee/Makefile | 3 +++
1 file changed, 3 insertions(+)
On Mon, 22 Mar 2021 at 16:11, Jerome Forissier via OP-TEE
<op-tee(a)lists.trustedfirmware.org> wrote:
>
> When Secure World returns, it may have changed the size attribute of the
> memory references passed as [in/out] parameters. The GlobalPlatform TEE
> Internal Core API specification does not restrict the values that this
> size can take. In particular, Secure World may increase the value to be
> larger than the size of the input buffer to indicate that it needs more.
>
> Therefore, the size check in optee_from_msg_param() is incorrect and
> needs to be removed. This fixes a number of failed test cases in the
> GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09
> when OP-TEE is compiled without dynamic shared memory support
> (CFG_CORE_DYN_SHM=n).
>
> Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org>
> Signed-off-by: Jerome Forissier <jerome(a)forissier.org>
> ---
> drivers/tee/optee/core.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
Looks good to me.
Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org>
-Sumit
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 319a1e701163..ddb8f9ecf307 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -79,16 +79,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params,
> return rc;
> p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa;
> p->u.memref.shm = shm;
> -
> - /* Check that the memref is covered by the shm object */
> - if (p->u.memref.size) {
> - size_t o = p->u.memref.shm_offs +
> - p->u.memref.size - 1;
> -
> - rc = tee_shm_get_pa(shm, o, NULL);
> - if (rc)
> - return rc;
> - }
> break;
> case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT:
> case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT:
> --
> 2.25.1
>
Hi,
I recently rebased a dev branch on top of next-20210330 (4143e05b7b17)
and I notice a build error from the optee driver:
In file included from drivers/tee/optee/call.c:18:
In file included from drivers/tee/optee/optee_trace.h:67:
./include/trace/define_trace.h:95:10: fatal error: './optee_trace.h' file not found
#include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
# define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
^~~~~~~~~~~~~~~~~~~~~~~
./include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
# define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
#define __stringify(x...) __stringify_1(x)
^~~~~~~~~~~~~~~~
./include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
#define __stringify_1(x...) #x
^~
<scratch space>:135:1: note: expanded from here
"./optee_trace.h"
^~~~~~~~~~~~~~~~~
1 error generated.
The config is attached. I am building using clang.
$ clang --version
clang version 11.1.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
--
Regards,
Pratyush Yadav
To += op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org>
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of François Ozog via TF-A
Sent: 26 March 2021 19:08
To: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
Cc: tf-a(a)lists.trustedfirmware.org; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
Subject: Re: [TF-A] Firmware FuSa workshop
Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt <xypron.glpk(a)gmx.de<mailto:xypron.glpk@gmx.de>> a écrit :
On 26.03.21 16:05, François Ozog wrote:
> Hi,
>
>
> Linaro is conducting an opportunity assessment to make OP-TEE ready for
> functional safety sensitive environments. The goal is to present a plan to
> Linaro members by the end of July 2021.
>
> The scope of the research is somewhat bigger because we can’t think of
> OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will
> though not address those (unless we recognize we have to). We don’t think
> U-Boot shall be part of the picture but we are welcoming contradictory
> points of views.
Hello François,
Some boards boot via SPL->TF-A->U-Boot. Here U-Boot's SPL is relevant
for OP-TEE's security.
U-Boot can save variables via OP-TEE (implemented by Ilias). In this
case OP-TEE has an implication on secure boot.
I fully understand that these scenarios are not in the focus of the
workshop.
it may if companies have this particular flow in mind for safety certification. Our goal is not to make all boot flows safety ready but to identify which ones we need to consider. And the workshop may help in this identification.
Best regards
Heinrich
>
> We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear
> about use cases and ideas about Long Term Support requirements . We will
> present the state of the research.
>
> The first use case is booting a safety certified type-1 hypervisor (open
> source or commercial is irrelevant).
>
> But we know there are many more: please be ready to contribute.
>
> We think of more radical use cases: a safety payload is actually loaded as
> a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device
> backends. In other words, Trust Zone hosts both safety and security worlds
> , EL3 being the « software root of trust » pivot world. In those cases,
> some cores never go out of secure state…
>
>
> Agenda (to be refined)
>
> -
>
> Vision
> -
>
> State of the research
> <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…>
> -
>
> Use cases discussion
> -
>
> What is the right scope?
> -
>
> “Who do what” discussion (LTS, archiving...)
> -
>
> Safety personnel (Linaro and contractors) discussion
> -
>
> Other considerations from participants?
> -
>
> Community organizations and funding?
> -
>
> Closing and next steps
>
>
> Should you want to participate and have not yet received an invite, please
> contact me directly.
>
> Cordially,
>
> François-Frédéric
>
> PS: Please reach out should you want another date with a time compatible
> with more time zones. This alternate date is not guaranteed though.
>
>
--
[https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…]
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog