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
On Mon, 19 Apr 2021 12:30:51 +0000
Joakim Bech via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> LOC monthly meeting is planned to take place Thursday April 29th(a)17.00
> (UTC+2).
>
> First, note that we have pushed the meeting forward one hour. If you
> subscribe to the meeting via the TrustedFirmware calendar, then your invite
> hopefully should've been updated (it could be worth cross checking).
>
> This month we will have Achin Gupta from Arm giving us an update regarding
> the evolution of FF-A and how that could work together with virtualization.
>
> Usually there is some time left over for other discussions. So if you
> have anything you'd like to talk about, then please let me know by replying
> to this email thread.
We at OMP would like to discuss GLOBEX - the REE/TEE synchronization mechanism
that we've proposed at https://github.com/OP-TEE/optee_os/issues/4539 .
It allows for sharing access to HW resources - something that came up
on the last contributors meeting.
We would like to present the design and hear your thoughts about it.
> Related to that, Linaro arranged an "OP-TEE readiness
> for safety" workshop last week. We're looking at all kinds of things
> related to that right now. But this is also something that we could touch
> in the LOC meeting. How would that affect upstream work? What code changes
> could we expect etc? Any expertise out there who would be interested in
> collaborating?
>
> OP-TEE 3.13.0 is planned to be released 2012-04-30, so in case you have any
> questions related to that, then the LOC meeting would be a good opportunity
> to ask.
>
> Meeting details:
> ---------------
> Date/time: Thursday April 29th(a)17.00 (UTC+2)
> https://everytimezone.com/s/c32cdcc3
> Connection details: https://www.trustedfirmware.org/meetings/
> Meeting notes: http://bit.ly/loc-notes
> Project page: https://www.linaro.org/projects#trusted-substrate_TS
>
> Regards,
> Joakim on behalf of the Linaro OP-TEE team
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.13.0 is scheduled to be released at 2021-04-30. 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/4552.
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,
Ruchika
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
Prior to this patch optee_open_session() was making assumptions about
the internal format of uuid_t by casting a memory location in a
parameter struct to uuid_t *. Fix this using export_uuid() to get a well
defined binary representation and also add an octets field in struct
optee_msg_param in order to avoid casting.
Fixes: c5b4312bea5d ("tee: optee: Add support for session login client UUID generation")
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>
---
drivers/tee/optee/call.c | 6 ++++--
drivers/tee/optee/optee_msg.h | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index 7a77e375b503..6b52f0c526ba 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -216,6 +216,7 @@ int optee_open_session(struct tee_context *ctx,
struct optee_msg_arg *msg_arg;
phys_addr_t msg_parg;
struct optee_session *sess = NULL;
+ uuid_t client_uuid;
/* +2 for the meta parameters added below */
shm = get_msg_arg(ctx, arg->num_params + 2, &msg_arg, &msg_parg);
@@ -236,10 +237,11 @@ int optee_open_session(struct tee_context *ctx,
memcpy(&msg_arg->params[0].u.value, arg->uuid, sizeof(arg->uuid));
msg_arg->params[1].u.value.c = arg->clnt_login;
- rc = tee_session_calc_client_uuid((uuid_t *)&msg_arg->params[1].u.value,
- arg->clnt_login, arg->clnt_uuid);
+ rc = tee_session_calc_client_uuid(&client_uuid, arg->clnt_login,
+ arg->clnt_uuid);
if (rc)
goto out;
+ export_uuid(msg_arg->params[1].u.octets, &client_uuid);
rc = optee_to_msg_param(msg_arg->params + 2, arg->num_params, param);
if (rc)
diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
index 81ff593ac4ec..e3d72d09c484 100644
--- a/drivers/tee/optee/optee_msg.h
+++ b/drivers/tee/optee/optee_msg.h
@@ -9,7 +9,7 @@
#include <linux/types.h>
/*
- * This file defines the OP-TEE message protocol used to communicate
+ * This file defines the OP-TEE message protocol (ABI) used to communicate
* with an instance of OP-TEE running in secure world.
*
* This file is divided into two sections.
@@ -144,9 +144,10 @@ struct optee_msg_param_value {
* @tmem: parameter by temporary memory reference
* @rmem: parameter by registered memory reference
* @value: parameter by opaque value
+ * @octets: parameter by octet string
*
* @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in
- * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value,
+ * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value or octets,
* OPTEE_MSG_ATTR_TYPE_TMEM_* indicates @tmem and
* OPTEE_MSG_ATTR_TYPE_RMEM_* indicates @rmem,
* OPTEE_MSG_ATTR_TYPE_NONE indicates that none of the members are used.
@@ -157,6 +158,7 @@ struct optee_msg_param {
struct optee_msg_param_tmem tmem;
struct optee_msg_param_rmem rmem;
struct optee_msg_param_value value;
+ u8 octets[24];
} u;
};
--
2.25.1
Hi,
LOC monthly meeting is planned to take place Thursday April 29th(a)17.00
(UTC+2).
First, note that we have pushed the meeting forward one hour. If you
subscribe to the meeting via the TrustedFirmware calendar, then your invite
hopefully should've been updated (it could be worth cross checking).
This month we will have Achin Gupta from Arm giving us an update regarding
the evolution of FF-A and how that could work together with virtualization.
Usually there is some time left over for other discussions. So if you
have anything you'd like to talk about, then please let me know by replying
to this email thread. Related to that, Linaro arranged an "OP-TEE readiness
for safety" workshop last week. We're looking at all kinds of things
related to that right now. But this is also something that we could touch
in the LOC meeting. How would that affect upstream work? What code changes
could we expect etc? Any expertise out there who would be interested in
collaborating?
OP-TEE 3.13.0 is planned to be released 2012-04-30, so in case you have any
questions related to that, then the LOC meeting would be a good opportunity
to ask.
Meeting details:
---------------
Date/time: Thursday April 29th(a)17.00 (UTC+2)
https://everytimezone.com/s/c32cdcc3
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Project page: https://www.linaro.org/projects#trusted-substrate_TS
Regards,
Joakim on behalf of the Linaro OP-TEE team