On Mon, Nov 29, 2021 at 04:31:51PM +0800, 994605959 wrote:
> maybe try this?
> - if (IS_ERR(*ta)) {
> - pr_err("%s: get_free_pages failed 0x%llx\n", __func__,
> - (u64)*ta);
> + if (IS_ERR(ta)) {
> + pr_err("%s: get_free_pages failed %p\n", __func__, ta);
No, what you are suggesting is totally wrong. You are checking the
wrong variable for the wrong thing.
regards,
dan carpenter
Hi,
OP-TEE Contributions (LOC) monthly meeting is planned for Thursday Nov 25
@17.00 (UTC+2).
Following topic is on the agenda:
- Walkthrough of proposal on sharing of hardware resources between multiple
secure entities - Jens Wiklander.
If you have any other topics you'd like to discuss, please let us know and
we can schedule them.
Meeting details:
---------------
Date/time: Nov 25(a)16.00 (UTC)
https://everytimezone.com/s/a43c71b2
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Regards,
Ruchika on behalf of the Linaro OP-TEE team
It appears that dynamic shared memory does not work with an embedded DT, but I'm likely missing something. I have it working fine with an external DT.
There is a bit of interaction in kernel/boot.c with the two configuration options and my testing is not seeing it work with 3.14 and master looks the same viewing it.
get_external_fdt() is called which does not work with the embedded DT it appears to me.
Any hints or advice?
Thanks
John
#ifdef CFG_CORE_DYN_SHM
static void discover_nsec_memory(void)
{
struct core_mmu_phys_mem *mem;
const struct core_mmu_phys_mem *mem_begin = NULL;
const struct core_mmu_phys_mem *mem_end = NULL;
size_t nelems;
void *fdt = get_external_dt();
if (fdt) {
mem = get_nsec_memory(fdt, &nelems);
if (mem) {
core_mmu_set_discovered_nsec_ddr(mem, nelems);
return;
}
DMSG("No non-secure memory found in FDT");
}
mem_begin = phys_ddr_overall_begin;
mem_end = phys_ddr_overall_end;
nelems = mem_end - mem_begin;
if (nelems) {
/*
* Platform cannot use both register_ddr() and the now
* deprecated register_dynamic_shm().
*/
assert(phys_ddr_overall_compat_begin ==
phys_ddr_overall_compat_end);
} else {
mem_begin = phys_ddr_overall_compat_begin;
mem_end = phys_ddr_overall_compat_end;
nelems = mem_end - mem_begin;
if (!nelems)
return;
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Hello arm-soc maintainers,
Please pull this small OP-TEE driver fix to avoid a possible NULL pointer
dereference in the error handling path of a probe function.
Thanks,
Jens
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-fix-for-v5.16
for you to fetch changes up to c23ca66a4dadb6f050dc57358bc8d57a747c35bf:
optee: fix kfree NULL pointer (2021-11-16 14:41:23 +0100)
----------------------------------------------------------------
Fix possible NULL pointer dereference in OP-TEE driver
----------------------------------------------------------------
Lv Ruyi (1):
optee: fix kfree NULL pointer
drivers/tee/optee/ffa_abi.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
Hi all,
This adds support for asynchronous notifications from OP-TEE in secure
world to the OP-TEE driver. This allows a design with a top half and bottom
half type of driver where the top half runs in secure interrupt context and
a notifications tells normal world to schedule a yielding call to do the
bottom half processing.
An interrupt is used to notify the driver that there are asynchronous
notifications pending.
v2->v3:
* Rebased on v5.14-rc2 which made the patch "dt-bindings: arm: Convert
optee binding to json-schema" from the V2 patch set obsolete.
* Applied Ard's Acked-by on "optee: add asynchronous notifications"
v1->v2:
* Added documentation
* Converted optee bindings to json-schema and added interrupt property
* Configure notification interrupt from DT instead of getting it
from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>.
Thanks,
Jens
Jens Wiklander (6):
docs: staging/tee.rst: add a section on OP-TEE notifications
dt-bindings: arm: optee: add interrupt property
tee: fix put order in teedev_close_context()
tee: add tee_dev_open_helper() primitive
optee: separate notification functions
optee: add asynchronous notifications
.../arm/firmware/linaro,optee-tz.yaml | 4 +
Documentation/staging/tee.rst | 27 +++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/call.c | 27 +++
drivers/tee/optee/core.c | 87 +++++--
drivers/tee/optee/notif.c | 226 ++++++++++++++++++
drivers/tee/optee/optee_msg.h | 9 +
drivers/tee/optee/optee_private.h | 23 +-
drivers/tee/optee/optee_rpc_cmd.h | 31 +--
drivers/tee/optee/optee_smc.h | 75 +++++-
drivers/tee/optee/rpc.c | 73 +-----
drivers/tee/tee_core.c | 37 ++-
include/linux/tee_drv.h | 27 +++
13 files changed, 523 insertions(+), 124 deletions(-)
create mode 100644 drivers/tee/optee/notif.c
--
2.31.1
Hi all,
This adds support for asynchronous notifications from OP-TEE in secure
world to the OP-TEE driver. This allows a design with a top half and bottom
half type of driver where the top half runs in secure interrupt context and
a notifications tells normal world to schedule a yielding call to do the
bottom half processing.
An edge-triggered interrupt is used to notify the driver that there are
asynchronous notifications pending.
Only the SMC based ABI of the OP-TEE driver gains asynchronous
notifications. Future support for asynchronous notifications in the FF-A
based ABI will rely on APIs which are expected to be provided by the FF-A
driver in a not too distant future.
This patchset is also available at
https://git.linaro.org/people/jens.wiklander/linux-tee.git/log/?h=async_not…
v7->v8:
* Fixed an error in "dt-bindings: arm: optee: add interrupt property"
reported by Rob's bot.
* "optee: add asynchronous notifications":
- Fixed a few spell errors in comments
- Added a missing optee_unregister_devices() in the cleanup path of
optee_probe().
- Added Sumit's Reviewed-by
v6->v7:
* Rebased on 4615e5a34b95 ("optee: add FF-A support") in
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git with
34f3c67b8178 ("optee: smc_abi.c: add missing #include <linux/mm.h>")
cherry-picked on top. This allows to resolve the conflicts with
pull request "[GIT PULL] OP-TEE FF-A for V5.16"
* Factored out the interrupt handling added in "optee: add asynchronous
notifications" to only go into smb_abi.c. A different approach is
expected with FF-A once it has asynchronous notifications.
* Addressed review comments from Sumit Garg:
- Replaced 0 and 1 with the macros GIC_SPI and IRQ_TYPE_EDGE_RISING in
the example in the bindings.
- Replaced the magic number to optee_notif_init() with
OPTEE_DEFAULT_MAX_NOTIF_VALUE in the commit "optee: separate notification
functions"
- Switched back to tagged error path in optee_probe()
- Fixed a few nits in "optee: add asynchronous notifications"
- Applied Sumit's Reviewed-by on all commits but the last,
"optee: add asynchronous notifications"
v5->v6:
* Rebased on v5.15-rc2
* Replaced "tee: add tee_dev_open_helper() primitive" with "tee: export
teedev_open() and teedev_close_context()" since it turned out that the
normal teedev functions could be used instead as noted by Sumit.
* Changed "optee: add asynchronous notifications" to use the exported
teedev_open() and teedev_close_context() functions instead.
v4->v5:
* Rebased on v5.14-rc7
* Updated documentation to clarify that one interrupt may represent multiple
notifications as requested.
* Applied Marc's and Rob's tags
v3->v4:
* Clarfied the expected type of interrypt is edge-triggered, both in
the normal documentation and in the DT bindings as requested.
v2->v3:
* Rebased on v5.14-rc2 which made the patch "dt-bindings: arm: Convert
optee binding to json-schema" from the V2 patch set obsolete.
* Applied Ard's Acked-by on "optee: add asynchronous notifications"
v1->v2:
* Added documentation
* Converted optee bindings to json-schema and added interrupt property
* Configure notification interrupt from DT instead of getting it
from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>.
Thanks,
Jens
Jens Wiklander (6):
docs: staging/tee.rst: add a section on OP-TEE notifications
dt-bindings: arm: optee: add interrupt property
tee: fix put order in teedev_close_context()
tee: export teedev_open() and teedev_close_context()
optee: separate notification functions
optee: add asynchronous notifications
.../arm/firmware/linaro,optee-tz.yaml | 8 +
Documentation/staging/tee.rst | 30 +++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/core.c | 2 +-
drivers/tee/optee/ffa_abi.c | 6 +-
drivers/tee/optee/notif.c | 125 +++++++++
drivers/tee/optee/optee_msg.h | 9 +
drivers/tee/optee/optee_private.h | 28 +-
drivers/tee/optee/optee_rpc_cmd.h | 31 ++-
drivers/tee/optee/optee_smc.h | 75 +++++-
drivers/tee/optee/rpc.c | 71 +-----
drivers/tee/optee/smc_abi.c | 241 +++++++++++++++---
drivers/tee/tee_core.c | 10 +-
include/linux/tee_drv.h | 14 +
14 files changed, 525 insertions(+), 126 deletions(-)
create mode 100644 drivers/tee/optee/notif.c
--
2.31.1
Hi all,
This adds support for asynchronous notifications from OP-TEE in secure
world to the OP-TEE driver. This allows a design with a top half and bottom
half type of driver where the top half runs in secure interrupt context and
a notifications tells normal world to schedule a yielding call to do the
bottom half processing.
An edge-triggered interrupt is used to notify the driver that there are
asynchronous notifications pending.
Only the SMC based ABI of the OP-TEE driver gains asynchronous
notifications. Future support for asynchronous notifications in the FF-A
based ABI will rely on APIs which are expected to be provided by the FF-A
driver in a not too distant future.
Most of the patches here are well reviewed, but the last patch "optee: add
asynchronous notifications" could do with some more attention.
This patchset is also available at
https://git.linaro.org/people/jens.wiklander/linux-tee.git/log/?h=async_not…
v6->v7:
* Rebased on 4615e5a34b95 ("optee: add FF-A support") in
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git with
34f3c67b8178 ("optee: smc_abi.c: add missing #include <linux/mm.h>")
cherry-picked on top. This allows to resolve the conflicts with
pull request "[GIT PULL] OP-TEE FF-A for V5.16"
* Factored out the interrupt handling added in "optee: add asynchronous
notifications" to only go into smb_abi.c. A different approach is
expected with FF-A once it has asynchronous notifications.
* Addressed review comments from Sumit Garg:
- Replaced 0 and 1 with the macros GIC_SPI and IRQ_TYPE_EDGE_RISING in
the example in the bindings.
- Replaced the magic number to optee_notif_init() with
OPTEE_DEFAULT_MAX_NOTIF_VALUE in the commit "optee: separate notification
functions"
- Switched back to tagged error path in optee_probe()
- Fixed a few nits in "optee: add asynchronous notifications"
- Applied Sumit's Reviewed-by on all commits but the last,
"optee: add asynchronous notifications"
v5->v6:
* Rebased on v5.15-rc2
* Replaced "tee: add tee_dev_open_helper() primitive" with "tee: export
teedev_open() and teedev_close_context()" since it turned out that the
normal teedev functions could be used instead as noted by Sumit.
* Changed "optee: add asynchronous notifications" to use the exported
teedev_open() and teedev_close_context() functions instead.
v4->v5:
* Rebased on v5.14-rc7
* Updated documentation to clarify that one interrupt may represent multiple
notifications as requested.
* Applied Marc's and Rob's tags
v3->v4:
* Clarfied the expected type of interrypt is edge-triggered, both in
the normal documentation and in the DT bindings as requested.
v2->v3:
* Rebased on v5.14-rc2 which made the patch "dt-bindings: arm: Convert
optee binding to json-schema" from the V2 patch set obsolete.
* Applied Ard's Acked-by on "optee: add asynchronous notifications"
v1->v2:
* Added documentation
* Converted optee bindings to json-schema and added interrupt property
* Configure notification interrupt from DT instead of getting it
from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>.
Thanks,
Jens
Jens Wiklander (6):
docs: staging/tee.rst: add a section on OP-TEE notifications
dt-bindings: arm: optee: add interrupt property
tee: fix put order in teedev_close_context()
tee: export teedev_open() and teedev_close_context()
optee: separate notification functions
optee: add asynchronous notifications
.../arm/firmware/linaro,optee-tz.yaml | 7 +
Documentation/staging/tee.rst | 30 +++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/core.c | 2 +-
drivers/tee/optee/ffa_abi.c | 6 +-
drivers/tee/optee/notif.c | 125 +++++++++
drivers/tee/optee/optee_msg.h | 9 +
drivers/tee/optee/optee_private.h | 28 ++-
drivers/tee/optee/optee_rpc_cmd.h | 31 +--
drivers/tee/optee/optee_smc.h | 75 +++++-
drivers/tee/optee/rpc.c | 71 +-----
drivers/tee/optee/smc_abi.c | 238 +++++++++++++++---
drivers/tee/tee_core.c | 10 +-
include/linux/tee_drv.h | 14 ++
14 files changed, 522 insertions(+), 125 deletions(-)
create mode 100644 drivers/tee/optee/notif.c
--
2.31.1
Hello arm-soc maintainers,
Please pull this small OP-TEE driver fix which takes care of a couple of
spell errors in a few log messages. These log messages was added in the
recently pulled 4615e5a34b95 ("optee: add FF-A support").
Thanks,
Jens
The following changes since commit 4615e5a34b95e0d81467f6d2176f19a5d184cb5d:
optee: add FF-A support (2021-10-18 11:44:23 +0200)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-ffa-fix-for-v5.16
for you to fetch changes up to 1b73a9e4986a4e9065bacf1e5ab2dfda17b54161:
optee: Fix spelling mistake "reclain" -> "reclaim" (2021-10-28 11:41:39 +0200)
----------------------------------------------------------------
Fix spell errors in OP-TEE FF-A driver log messages
----------------------------------------------------------------
Colin Ian King (1):
optee: Fix spelling mistake "reclain" -> "reclaim"
drivers/tee/optee/ffa_abi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi,
OP-TEE Contributions (LOC) monthly meeting is planned for Thursday Oct 28
@17.00 (UTC+2).
Following topics are on the agenda:
- Generic Clock Framework and Peripheral security- Clément Léger
- Discussion on device driver initialization/probing - Etienne Carriere
If you have any other topics you'd like to discuss, please let us know and
we can schedule them.
Meeting details:
---------------
Date/time: October 28(a)17.00 (UTC+2)
https://everytimezone.com/s/3f83a9ab
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Regards,
Ruchika on behalf of the Linaro OP-TEE team
Hello arm-soc maintainers,
Please pull these patches which adds support for FF-A [1] in the OP-TEE
driver. There's a bit of shuffling in the code where everyhting related to
the old SMC based ABI is moved to drivers/tee/optee/smc_abi.c, but there
should not be any changed in behavior for with the old ABI.
Note that this is based on top of the recent fix 7f565d0ead26 ("tee: optee:
Fix missing devices unregister during optee_remove") which has already been
requested to be pulled.
Thanks,
Jens
The following changes since commit 7f565d0ead264329749c0da488de9c8dfa2f18ce:
tee: optee: Fix missing devices unregister during optee_remove (2021-10-12 13:24:39 +0200)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-ffa-for-v5.16
for you to fetch changes up to 4615e5a34b95e0d81467f6d2176f19a5d184cb5d:
optee: add FF-A support (2021-10-18 11:44:23 +0200)
----------------------------------------------------------------
Add FF-A support in OP-TEE driver
Adds supports for the OP-TEE driver to communicate with secure world
using FF-A [1] as transport.
[1] https://developer.arm.com/documentation/den0077/latest
----------------------------------------------------------------
Jens Wiklander (5):
tee: add sec_world_id to struct tee_shm
optee: simplify optee_release()
optee: refactor driver with internal callbacks
optee: isolate smc abi
optee: add FF-A support
drivers/tee/optee/Makefile | 5 +-
drivers/tee/optee/call.c | 445 ++----------
drivers/tee/optee/core.c | 719 ++------------------
drivers/tee/optee/ffa_abi.c | 911 +++++++++++++++++++++++++
drivers/tee/optee/optee_ffa.h | 153 +++++
drivers/tee/optee/optee_msg.h | 27 +-
drivers/tee/optee/optee_private.h | 157 ++++-
drivers/tee/optee/rpc.c | 237 +------
drivers/tee/optee/shm_pool.c | 101 ---
drivers/tee/optee/shm_pool.h | 14 -
drivers/tee/optee/smc_abi.c | 1361 +++++++++++++++++++++++++++++++++++++
include/linux/tee_drv.h | 7 +-
12 files changed, 2728 insertions(+), 1409 deletions(-)
create mode 100644 drivers/tee/optee/ffa_abi.c
create mode 100644 drivers/tee/optee/optee_ffa.h
delete mode 100644 drivers/tee/optee/shm_pool.c
delete mode 100644 drivers/tee/optee/shm_pool.h
create mode 100644 drivers/tee/optee/smc_abi.c
Hi all,
This adds supports for the OP-TEE driver to communicate with secure world
using FF-A [1] as transport.
There is one change to the TEE subsystem with "tee: add sec_world_id to
struct tee_shm" to add support for holding globally unique handle assigned
by the FF-A. This is a field that I believe could useful for the AMDTEE
driver too.
For communication the OP-TEE message protocol is still used, but with a new
type of memory reference, struct optee_msg_param_fmem, to carry the
information needed by FF-A. The OP-TEE driver is refactored internally with
to sets of callbacks, one for the old SMC based communication and another
set with FF-A as transport. The functions relating to the SMC based ABI
are moved to smc_abi.c while the FF-A based ABI is added in a ffa_abi.c.
There is also a difference in how the drivers are instantiated. With the
SMC based transport we have a platform driver, module_platform_driver(),
today which we're keeping as is for this configuration. In a FF-A system we
have a FF-A driver, module_ffa_driver(), instead.
The OP-TEE driver can be compiled for both targets at the same time and
it's up to runtime configuration (device tree or ACPI) to decide how it's
initialized. Note that it's only the old SMC based driver instance that
need device tree or ACPI to initialize. The FF-A based driver relies on the
FF-A bus instead.
These patches are also available at
https://git.linaro.org/people/jens.wiklander/linux-tee.git/log/?h=optee_ffa…
Note that there's three patches there not included in this patchset
"tee/optee/shm_pool: fix application of sizeof to pointer",
"firmware: arm_ffa: Fix __ffa_devices_unregister" and
"firmware: arm_ffa: Add missing remove callback to ffa_bus_type"
already have or are about to be sent to arm-soc with separate pull requests.
This can be tested QEMU
The repo for SPMC at S-EL1 retrieved by
repo init -u https://github.com/jenswi-linaro/manifest.git -m
qemu_v8.xml -b ffav4_spmc
repo sync
# Then checkout the branch optee_ffa_v6 from
# git://git.linaro.org/people/jens.wiklander/linux-tee.git
# in the linux directory
To build do:
cd build
make toolchains
make all
To boot:
make run-only
Test with xtest, perhaps only with the command "xtest 1004" in case you're
not interested in too many tests.
Thanks,
Jens
[1] https://developer.arm.com/documentation/den0077/latest
v5->v6:
- Rebased on v5.15-rc2
- Addressing comments from Sudeep Holla to work with ARM_FFA_TRANSPORT=m
- Fixing a couple of warnings in "optee: isolate smc abi" reported by
kernel test robot <lkp(a)intel.com>
- Adding the fix from "tee/optee/shm_pool: fix application of sizeof to
pointer" into "optee: isolate smc abi" since the function code has been
moved to another file.
v4->v5:
- Rebased on v5.14, tricky conflicts primarily between "optee: isolate smc
abi" and mostly 376e4199e327 "tee: Correct inappropriate usage of
TEE_SHM_DMA_BUF flag" but also with the other kexec fixes that went into
v5.14-rc5.
- Addressing comments from Sumit and applying
Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> on "optee: isolate smc abi"
- Addressing comments from Sumit and applying
Acked-by: Sumit Garg <sumit.garg(a)linaro.org> on "optee: add FF-A support"
v3->v4:
- Made a bit more RPC code common between the SMC and FF-A ABIs as
requested by Sumit.
- Replaced module_platform_driver() with module_init()/module_exit() as
described in the commit "optee: isolate smc abi".
- Applied Sumit's R-B for the commits "tee: add sec_world_id to struct
tee_shm", "optee: simplify optee_release()", and "optee: refactor driver
with internal callbacks"
v2->v3:
- Rebased on 5.14-rc2 which now have the FF-A patches merged
- Fixed a couple bugs in optee_shm_register() and optee_shm_unregister()
which where introduced in "optee: refactor driver with internal callbacks"
in previous the version.
- Separated SMC ABI specifics into smc_abi.c to keep it separated from
the FF-A ABI functions as requested by Sumit.
- Added the FF-A specifics in ffa_abi.c
- Provided an implementation for optee_ffa_remove()
v1->v2:
- Rebased to the FF-A v7 patch
- Fixed a couple of reports from kernel test robot <lkp(a)intel.com>
Jens Wiklander (5):
tee: add sec_world_id to struct tee_shm
optee: simplify optee_release()
optee: refactor driver with internal callbacks
optee: isolate smc abi
optee: add FF-A support
drivers/tee/optee/Makefile | 5 +-
drivers/tee/optee/call.c | 445 ++--------
drivers/tee/optee/core.c | 719 ++-------------
drivers/tee/optee/ffa_abi.c | 911 +++++++++++++++++++
drivers/tee/optee/optee_ffa.h | 153 ++++
drivers/tee/optee/optee_msg.h | 27 +-
drivers/tee/optee/optee_private.h | 155 +++-
drivers/tee/optee/rpc.c | 237 +----
drivers/tee/optee/shm_pool.c | 101 ---
drivers/tee/optee/shm_pool.h | 14 -
drivers/tee/optee/smc_abi.c | 1360 +++++++++++++++++++++++++++++
include/linux/tee_drv.h | 7 +-
12 files changed, 2726 insertions(+), 1408 deletions(-)
create mode 100644 drivers/tee/optee/ffa_abi.c
create mode 100644 drivers/tee/optee/optee_ffa.h
delete mode 100644 drivers/tee/optee/shm_pool.c
delete mode 100644 drivers/tee/optee/shm_pool.h
create mode 100644 drivers/tee/optee/smc_abi.c
--
2.31.1
Hi all,
This adds support for asynchronous notifications from OP-TEE in secure
world to the OP-TEE driver. This allows a design with a top half and bottom
half type of driver where the top half runs in secure interrupt context and
a notifications tells normal world to schedule a yielding call to do the
bottom half processing.
An edge-triggered interrupt is used to notify the driver that there are
asynchronous notifications pending.
The documentation and DT bindings patches are now well reviewed, but
the patches with code would do with some more attention.
v5->v6:
* Rebased on v5.15-rc2
* Replaced "tee: add tee_dev_open_helper() primitive" with "tee: export
teedev_open() and teedev_close_context()" since it turned out that the
normal teedev functions could be used instead as noted by Sumit.
* Changed "optee: add asynchronous notifications" to use the exported
teedev_open() and teedev_close_context() functions instead.
v4->v5:
* Rebased on v5.14-rc7
* Updated documentation to clarify that one interrupt may represent multiple
notifications as requested.
* Applied Marc's and Rob's tags
v3->v4:
* Clarfied the expected type of interrypt is edge-triggered, both in
the normal documentation and in the DT bindings as requested.
v2->v3:
* Rebased on v5.14-rc2 which made the patch "dt-bindings: arm: Convert
optee binding to json-schema" from the V2 patch set obsolete.
* Applied Ard's Acked-by on "optee: add asynchronous notifications"
v1->v2:
* Added documentation
* Converted optee bindings to json-schema and added interrupt property
* Configure notification interrupt from DT instead of getting it
from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>.
Thanks,
Jens
Jens Wiklander (6):
docs: staging/tee.rst: add a section on OP-TEE notifications
dt-bindings: arm: optee: add interrupt property
tee: fix put order in teedev_close_context()
tee: export teedev_open() and teedev_close_context()
optee: separate notification functions
optee: add asynchronous notifications
.../arm/firmware/linaro,optee-tz.yaml | 7 +
Documentation/staging/tee.rst | 30 +++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/call.c | 27 +++
drivers/tee/optee/core.c | 87 +++++--
drivers/tee/optee/notif.c | 226 ++++++++++++++++++
drivers/tee/optee/optee_msg.h | 9 +
drivers/tee/optee/optee_private.h | 23 +-
drivers/tee/optee/optee_rpc_cmd.h | 31 +--
drivers/tee/optee/optee_smc.h | 75 +++++-
drivers/tee/optee/rpc.c | 73 +-----
drivers/tee/tee_core.c | 10 +-
include/linux/tee_drv.h | 14 ++
13 files changed, 496 insertions(+), 117 deletions(-)
create mode 100644 drivers/tee/optee/notif.c
--
2.31.1
Hello arm-soc maintainers,
Please pull this OP-TEE driver fix to unregister OP-TEE client devices
from the TEE bus when the OP-TEE driver is unloaded.
Note that this is based on the previous already merged OP-TEE driver
fix.
Thanks,
Jens
The following changes since commit 88a3856c0a8c03188db7913f4d49379432fe1f93:
tee/optee/shm_pool: fix application of sizeof to pointer (2021-09-14 07:54:56 +0200)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-fix2-for-v5.15
for you to fetch changes up to 7f565d0ead264329749c0da488de9c8dfa2f18ce:
tee: optee: Fix missing devices unregister during optee_remove (2021-10-12 13:24:39 +0200)
----------------------------------------------------------------
Fix missing devices unregister during optee_remove
Unregisters OP-TEE client devices (UUIDs of some known Trusted
Applications) from the TEE bus when the OP-TEE driver is unloaded.
----------------------------------------------------------------
Sumit Garg (1):
tee: optee: Fix missing devices unregister during optee_remove
drivers/tee/optee/core.c | 3 +++
drivers/tee/optee/device.c | 22 ++++++++++++++++++++++
drivers/tee/optee/optee_private.h | 1 +
3 files changed, 26 insertions(+)
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.15.0 is scheduled to be released on 2021-10-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/4880
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
Hi,
First of all, as I don't see a lot of questions being asked here, so
please feel free to direct me elsewhere with my question(s) if this is
not the proper place to do so.
In our application, we are using a custom Optee PTA to control our
display securely. Our user space application utilizes LVGL with a
custom LVGL Optee PTA driver, which allocates TEEC_SharedMemory using
TEEC_AllocateSharedMemory() for the frame buffer, which transferred as
TEEC_MEMREF_WHOLE to our custom PTA by our custom LVGL Optee-PTA
driver whenever LVGL flushes its frame buffer.
Our user space application also starts and stops several LXC containers.
We noticed that after starting any LXC container, our display freezes.
In this scenario, our custom LVGL Optee PTA driver is still pushing
newly updated frame buffer contents to our custom Optee PTA, but the
buffer received by our custom Optee PTA contains old data.
We have traced down the cause to a fork() call in lxc_start();
Replacing lxc_start() with fork() has the same effect, hence we think
the problem is caused by fork(). After fork, updates from neither the
parent nor the child appear in the buffer at our custom Optee PTA end.
We wonder if this is by design, as shared memory in combination with
fork() might be a security hazard, exposing memory shared with the
secure world to any forked process. Are we right? We really would like
to understand this.
If, instead of using TEEC_AllocateSharedMemory() and
TEEC_MEMREF_WHOLE, we use calloc() and TEEC_MEMREF_WHOLE instead, the
problem does not occur. Probably because the memory is mapped at each
use. Is this the suggested work-around?
Thank you in advance.
With kind regards,
Robert Deliën.
--
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.
Hello arm-soc maintainers,
Please pull this small OP-TEE driver fix for the shared memory pool
handler. The fix doesn't change the generated code, but it's still relevant
since the problem obviously triggers warnings with some tools.
Thanks,
Jens
The following changes since commit 7d2a07b769330c34b4deabeed939325c77a7ec2f:
Linux 5.14 (2021-08-29 15:04:50 -0700)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-fix-for-v5.15
for you to fetch changes up to 88a3856c0a8c03188db7913f4d49379432fe1f93:
tee/optee/shm_pool: fix application of sizeof to pointer (2021-09-14 07:54:56 +0200)
----------------------------------------------------------------
Fix OP-TEE shm_pool lint warning
----------------------------------------------------------------
jing yangyang (1):
tee/optee/shm_pool: fix application of sizeof to pointer
drivers/tee/optee/shm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi all,
This adds supports for the OP-TEE driver to communicate with secure world
using FF-A [1] as transport.
There is one change to the TEE subsystem with "tee: add sec_world_id to
struct tee_shm" to add support for holding globally unique handle assigned
by the FF-A. This is a field that I believe could useful for the AMDTEE
driver too.
For communication the OP-TEE message protocol is still used, but with a new
type of memory reference, struct optee_msg_param_fmem, to carry the
information needed by FF-A. The OP-TEE driver is refactored internally with
to sets of callbacks, one for the old SMC based communication and another
set with FF-A as transport. The functions relating to the SMC based ABI
are moved to smc_abi.c while the FF-A based ABI is added in a ffa_abi.c.
There is also a difference in how the drivers are instantiated. With the
SMC based transport we have a platform driver, module_platform_driver(),
today which we're keeping as is for this configuration. In a FF-A system we
have a FF-A driver, module_ffa_driver(), instead.
The OP-TEE driver can be compiled for both targets at the same time and
it's up to runtime configuration (device tree or ACPI) to decide how it's
initialized. Note that it's only the old SMC based driver instance that
need device tree or ACPI to initialize. The FF-A based driver relies on the
FF-A bus instead.
This can be tested QEMU
The repo for SPMC at S-EL1 retrieved by
repo init -u https://github.com/jenswi-linaro/manifest.git -m
qemu_v8.xml -b ffav4_spmc
repo sync
# Then checkout the branch optee_ffa_v5 from
# git://git.linaro.org/people/jens.wiklander/linux-tee.git
# in the linux directory
To build do:
cd build
make toolchains
make all
To boot:
make run-only
Test with xtest, perhaps only with the command "xtest 1004" in case you're
not interested in too many tests.
Thanks,
Jens
[1] https://developer.arm.com/documentation/den0077/latest
v4->v5:
- Rebased on v5.14, tricky conflicts primarily between "optee: isolate smc
abi" and mostly 376e4199e327 "tee: Correct inappropriate usage of
TEE_SHM_DMA_BUF flag" but also with the other kexec fixes that went into
v5.14-rc5.
- Addressing comments from Sumit and applying
Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> on "optee: isolate smc abi"
- Addressing comments from Sumit and applying
Acked-by: Sumit Garg <sumit.garg(a)linaro.org> on "optee: add FF-A support"
v3->v4:
- Made a bit more RPC code common between the SMC and FF-A ABIs as
requested by Sumit.
- Replaced module_platform_driver() with module_init()/module_exit() as
described in the commit "optee: isolate smc abi".
- Applied Sumit's R-B for the commits "tee: add sec_world_id to struct
tee_shm", "optee: simplify optee_release()", and "optee: refactor driver
with internal callbacks"
v2->v3:
- Rebased on 5.14-rc2 which now have the FF-A patches merged
- Fixed a couple bugs in optee_shm_register() and optee_shm_unregister()
which where introduced in "optee: refactor driver with internal callbacks"
in previous the version.
- Separated SMC ABI specifics into smc_abi.c to keep it separated from
the FF-A ABI functions as requested by Sumit.
- Added the FF-A specifics in ffa_abi.c
- Provided an implementation for optee_ffa_remove()
v1->v2:
- Rebased to the FF-A v7 patch
- Fixed a couple of reports from kernel test robot <lkp(a)intel.com>
Jens Wiklander (5):
tee: add sec_world_id to struct tee_shm
optee: simplify optee_release()
optee: refactor driver with internal callbacks
optee: isolate smc abi
optee: add FF-A support
drivers/tee/optee/Makefile | 7 +-
drivers/tee/optee/call.c | 445 ++--------
drivers/tee/optee/core.c | 719 ++-------------
drivers/tee/optee/ffa_abi.c | 907 +++++++++++++++++++
drivers/tee/optee/optee_ffa.h | 153 ++++
drivers/tee/optee/optee_msg.h | 27 +-
drivers/tee/optee/optee_private.h | 163 +++-
drivers/tee/optee/rpc.c | 237 +----
drivers/tee/optee/shm_pool.c | 101 ---
drivers/tee/optee/shm_pool.h | 14 -
drivers/tee/optee/smc_abi.c | 1360 +++++++++++++++++++++++++++++
include/linux/tee_drv.h | 7 +-
12 files changed, 2732 insertions(+), 1408 deletions(-)
create mode 100644 drivers/tee/optee/ffa_abi.c
create mode 100644 drivers/tee/optee/optee_ffa.h
delete mode 100644 drivers/tee/optee/shm_pool.c
delete mode 100644 drivers/tee/optee/shm_pool.h
create mode 100644 drivers/tee/optee/smc_abi.c
--
2.31.1
Hi,
I met an issue when testing OP-TEE with the latest released kernel
(v5.14). The kernel won't boot when virtualization is enabled. More
precisely, the boot hangs as the optee driver is probed. The last line
on the console is:
[xxx] optee: probing for conduit method.
The issue can easily be reproduced in the QEMU OP-TEE environment as
documented in [1]:
$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
$ repo sync -j10
$ cd linux
$ git fetch github --unshallow
$ git checkout v5.14
$ cd ../build
$ make -j2 toolchains
$ make -j10 XEN_BOOT=y run
[Note, if you switch between XEN_BOOT=y and the default build, you need
to "make arm-tf-clean"]
git bisect points at commit b5c10dd04b74 ("optee: Clear stale cache
entries during initialization") and reverting this commit on top of
v5.14 does resolve the issue.
Any idea what's wrong?
[1]
https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
Thanks,
--
Jerome
Commit ef30482b4ad6 ("plat-vexpress: FF-A: update secondary core init")
updated secondary core init for the vexpress platform. In the process,
it used FFA_SECONDARY_EP_REGISTER with FID 0xC4000084 based on the ALP0
ABI of the spec and the TF-A upstream implementation at the time with a
note that the function ID needs to updated to the one finalied in the
spec and the TF-A implementation.
Assuming it is all finalised now, let us update the same with correct/
updated FID 0xC4000087.
Cc: Jens Wiklander <jens.wiklander(a)linaro.org>
Cc: Olivier Deprez <olivier.deprez(a)arm.com>
Cc: Balint Dobszay <balint.dobszay(a)arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
---
core/arch/arm/include/ffa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/core/arch/arm/include/ffa.h b/core/arch/arm/include/ffa.h
index 20a009cacabd..b0d68173bf80 100644
--- a/core/arch/arm/include/ffa.h
+++ b/core/arch/arm/include/ffa.h
@@ -69,7 +69,7 @@
#define FFA_MEM_RECLAIM U(0x84000077)
#define FFA_MEM_FRAG_RX U(0x8400007A)
#define FFA_MEM_FRAG_TX U(0x8400007B)
-#define FFA_SECONDARY_EP_REGISTER_64 U(0xC4000084)
+#define FFA_SECONDARY_EP_REGISTER_64 U(0xC4000087)
/* Special value for traffic targeted to the Hypervisor or SPM */
#define FFA_TARGET_INFO_MBZ U(0x0)
--
2.25.1
Hi,
Linaro OP-TEE Contributions (LOC) monthly meeting is planned to take place
on Thursday Sep 23(a)17.00 (UTC+2).
Following topics are on the agenda:
- OP-TEE Linaro Contribution - Current status and Roadmap - Ruchika
- FF-A based mediator in XEN - Jens
If you have any other topics you'd like to discuss, please let us know.
Meeting details:
---------------
Date/time: Thursday Sep 23(a)17.00 (UTC+2)
https://everytimezone.com/s/35c9885e
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Regards,
Ruchika on behalf of the Linaro OP-TEE team
Hi all,
This adds support for asynchronous notifications from OP-TEE in secure
world to the OP-TEE driver. This allows a design with a top half and bottom
half type of driver where the top half runs in secure interrupt context and
a notifications tells normal world to schedule a yielding call to do the
bottom half processing.
An edge-triggered interrupt is used to notify the driver that there are
asynchronous notifications pending.
The documentation and DT bindings patches are now well reviewed, but
the patches with code would do with some more attention.
v4->v5:
* Rebased on v5.14-rc7
* Updated documentation to clarify that one interrupt may represent multiple
notifications as requested.
* Applied Marc's and Rob's tags
v3->v4:
* Clarfied the expected type of interrypt is edge-triggered, both in
the normal documentation and in the DT bindings as requested.
v2->v3:
* Rebased on v5.14-rc2 which made the patch "dt-bindings: arm: Convert
optee binding to json-schema" from the V2 patch set obsolete.
* Applied Ard's Acked-by on "optee: add asynchronous notifications"
v1->v2:
* Added documentation
* Converted optee bindings to json-schema and added interrupt property
* Configure notification interrupt from DT instead of getting it
from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>.
Thanks,
Jens
Jens Wiklander (6):
docs: staging/tee.rst: add a section on OP-TEE notifications
dt-bindings: arm: optee: add interrupt property
tee: fix put order in teedev_close_context()
tee: add tee_dev_open_helper() primitive
optee: separate notification functions
optee: add asynchronous notifications
.../arm/firmware/linaro,optee-tz.yaml | 7 +
Documentation/staging/tee.rst | 30 +++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/call.c | 27 +++
drivers/tee/optee/core.c | 87 +++++--
drivers/tee/optee/notif.c | 226 ++++++++++++++++++
drivers/tee/optee/optee_msg.h | 9 +
drivers/tee/optee/optee_private.h | 23 +-
drivers/tee/optee/optee_rpc_cmd.h | 31 +--
drivers/tee/optee/optee_smc.h | 75 +++++-
drivers/tee/optee/rpc.c | 73 +-----
drivers/tee/tee_core.c | 37 ++-
include/linux/tee_drv.h | 27 +++
13 files changed, 529 insertions(+), 124 deletions(-)
create mode 100644 drivers/tee/optee/notif.c
--
2.31.1
Hi all,
This adds supports for the OP-TEE driver to communicate with secure world
using FF-A [1] as transport.
There is one change to the TEE subsystem with "tee: add sec_world_id to
struct tee_shm" to add support for holding globally unique handle assigned
by the FF-A. This is a field that I believe could useful for the AMDTEE
driver too.
For communication the OP-TEE message protocol is still used, but with a new
type of memory reference, struct optee_msg_param_fmem, to carry the
information needed by FF-A. The OP-TEE driver is refactored internally with
to sets of callbacks, one for the old SMC based communication and another
set with FF-A as transport. The functions relating to the SMC based ABI
are moved to smc_abi.c while the FF-A based ABI is added in a ffa_abi.c.
There is also a difference in how the drivers are instantiated. With the
SMC based transport we have a platform driver, module_platform_driver(),
today which we're keeping as is for this configuration. In a FF-A system we
have a FF-A driver, module_ffa_driver(), instead.
The OP-TEE driver can be compiled for both targets at the same time and
it's up to runtime configuration (device tree or ACPI) to decide how it's
initialized. Note that it's only the old SMC based driver instance that
need device tree or ACPI to initialize. The FF-A based driver relies on the
FF-A bus instead.
This can be tested QEMU
The repo for SPMC at S-EL1 retrieved by
repo init -u https://github.com/jenswi-linaro/manifest.git -m
qemu_v8.xml -b ffav4_spmc
repo sync
# Then checkout the branch optee_ffa_v4 from
# git://git.linaro.org/people/jens.wiklander/linux-tee.git
# in the linux directory
To build do:
cd build
make toolchains
make all
To boot:
make run-only
Test with xtest, perhaps only with the command "xtest 1004" in case you're
not interested in too many tests.
Thanks,
Jens
[1] https://developer.arm.com/documentation/den0077/latest
v3->v4:
- Made a bit more RPC code common between the SMC and FF-A ABIs as
requested by Sumit.
- Replaced module_platform_driver() with module_init()/module_exit() as
described in the commit "optee: isolate smc abi".
- Applied Sumit's R-B for the commits "tee: add sec_world_id to struct
tee_shm", "optee: simplify optee_release()", and "optee: refactor driver
with internal callbacks"
v2->v3:
- Rebased on 5.14-rc2 which now have the FF-A patches merged
- Fixed a couple bugs in optee_shm_register() and optee_shm_unregister()
which where introduced in "optee: refactor driver with internal callbacks"
in previous the version.
- Separated SMC ABI specifics into smc_abi.c to keep it separated from
the FF-A ABI functions as requested by Sumit.
- Added the FF-A specifics in ffa_abi.c
- Provided an implementation for optee_ffa_remove()
v1->v2:
- Rebased to the FF-A v7 patch
- Fixed a couple of reports from kernel test robot <lkp(a)intel.com>
Jens Wiklander (5):
tee: add sec_world_id to struct tee_shm
optee: simplify optee_release()
optee: refactor driver with internal callbacks
optee: isolate smc abi
optee: add FF-A support
drivers/tee/optee/Makefile | 7 +-
drivers/tee/optee/call.c | 415 ++-------
drivers/tee/optee/core.c | 685 ++-------------
drivers/tee/optee/ffa_abi.c | 907 ++++++++++++++++++++
drivers/tee/optee/optee_ffa.h | 153 ++++
drivers/tee/optee/optee_msg.h | 27 +-
drivers/tee/optee/optee_private.h | 162 +++-
drivers/tee/optee/rpc.c | 236 +-----
drivers/tee/optee/shm_pool.c | 89 --
drivers/tee/optee/shm_pool.h | 14 -
drivers/tee/optee/smc_abi.c | 1299 +++++++++++++++++++++++++++++
include/linux/tee_drv.h | 7 +-
12 files changed, 2665 insertions(+), 1336 deletions(-)
create mode 100644 drivers/tee/optee/ffa_abi.c
create mode 100644 drivers/tee/optee/optee_ffa.h
delete mode 100644 drivers/tee/optee/shm_pool.c
delete mode 100644 drivers/tee/optee/shm_pool.h
create mode 100644 drivers/tee/optee/smc_abi.c
--
2.31.1
Hi,
The meeting was supposed to take place today, but it's still vacation time
and we have nothing on the agenda, hence I'm cancelling this month's
meeting. Next month things should be back to normal, so see you then.
Regards,
Joakim on behalf of the Linaro OP-TEE team
Hi all,
This adds support for asynchronous notifications from OP-TEE in secure
world to the OP-TEE driver. This allows a design with a top half and bottom
half type of driver where the top half runs in secure interrupt context and
a notifications tells normal world to schedule a yielding call to do the
bottom half processing.
An edge-triggered interrupt is used to notify the driver that there are
asynchronous notifications pending.
v3->v4:
* Clarfied the expected type of interrypt is edge-triggered, both in
the normal documentation and in the DT bindings as requested.
v2->v3:
* Rebased on v5.14-rc2 which made the patch "dt-bindings: arm: Convert
optee binding to json-schema" from the V2 patch set obsolete.
* Applied Ard's Acked-by on "optee: add asynchronous notifications"
v1->v2:
* Added documentation
* Converted optee bindings to json-schema and added interrupt property
* Configure notification interrupt from DT instead of getting it
from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>.
Thanks,
Jens
Jens Wiklander (6):
docs: staging/tee.rst: add a section on OP-TEE notifications
dt-bindings: arm: optee: add interrupt property
tee: fix put order in teedev_close_context()
tee: add tee_dev_open_helper() primitive
optee: separate notification functions
optee: add asynchronous notifications
.../arm/firmware/linaro,optee-tz.yaml | 7 +
Documentation/staging/tee.rst | 29 +++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/call.c | 27 +++
drivers/tee/optee/core.c | 87 +++++--
drivers/tee/optee/notif.c | 226 ++++++++++++++++++
drivers/tee/optee/optee_msg.h | 9 +
drivers/tee/optee/optee_private.h | 23 +-
drivers/tee/optee/optee_rpc_cmd.h | 31 +--
drivers/tee/optee/optee_smc.h | 75 +++++-
drivers/tee/optee/rpc.c | 73 +-----
drivers/tee/tee_core.c | 37 ++-
include/linux/tee_drv.h | 27 +++
13 files changed, 528 insertions(+), 124 deletions(-)
create mode 100644 drivers/tee/optee/notif.c
--
2.31.1
When the system is going to hibernate or suspend it might happen
that the tee-supplicant task is frozen first.
In this case a running OP-TEE task might get stuck in the loop using
wait_for_completion_interruptible to wait for response of tee-supplicant.
As a consequence other OP-TEE tasks waiting for the above or a
succeeding stuck OP-TEE task might get stuck as well
- waiting for call queue entry to be completed
- waiting for OPTEE_RPC_WAIT_QUEUE_WAKEUP
This will result in the tasks "refusing to freeze" and
the hibernate or suspend will fail.
OP-TEE issue: https://github.com/OP-TEE/optee_os/issues/4581
- Read back the object
PM: suspend entry (s2idle)
Filesystems sync: 0.000 seconds
Freezing user space processes ...
Freezing of tasks failed after 20.008 seconds (3 tasks refusing to freeze, wq_busy=0):
task:optee_example_s state:R running task stack: 0 pid: 124 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<841c4000>] (0x841c4000)
task:optee_example_s state:D stack: 0 pid: 126 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120)
[<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340)
[<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc)
[<807d56a0>] (wait_for_completion) from [<80692134>] (optee_cq_wait_for_completion+0x14/0x60)
[<80692134>] (optee_cq_wait_for_completion) from [<806924dc>] (optee_do_call_with_arg+0x14c/0x154)
[<806924dc>] (optee_do_call_with_arg) from [<80692edc>] (optee_shm_unregister+0x78/0xcc)
[<80692edc>] (optee_shm_unregister) from [<80690a9c>] (tee_shm_release+0x88/0x174)
[<80690a9c>] (tee_shm_release) from [<8057f89c>] (dma_buf_release+0x44/0xb0)
[<8057f89c>] (dma_buf_release) from [<8028e4e8>] (__dentry_kill+0x110/0x17c)
[<8028e4e8>] (__dentry_kill) from [<80276cfc>] (__fput+0xc0/0x234)
[<80276cfc>] (__fput) from [<80140b1c>] (task_work_run+0x90/0xbc)
[<80140b1c>] (task_work_run) from [<8010b1c8>] (do_work_pending+0x4a0/0x5a0)
[<8010b1c8>] (do_work_pending) from [<801000cc>] (slow_work_pending+0xc/0x20)
Exception stack(0x843f5fb0 to 0x843f5ff8)
5fa0: 00000000 7ef63448 fffffffe 00000000
5fc0: 7ef63448 76f163b0 7ef63448 00000006 7ef63448 7ef634e0 7ef63438 00000000
5fe0: 00000006 7ef63400 76e74833 76dff856 800e0130 00000004
task:optee_example_s state:D stack: 0 pid: 128 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120)
[<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340)
[<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc)
[<807d56a0>] (wait_for_completion) from [<8069359c>] (optee_handle_rpc+0x554/0x710)
[<8069359c>] (optee_handle_rpc) from [<806924cc>] (optee_do_call_with_arg+0x13c/0x154)
[<806924cc>] (optee_do_call_with_arg) from [<80692910>] (optee_invoke_func+0x110/0x190)
[<80692910>] (optee_invoke_func) from [<8068fe3c>] (tee_ioctl+0x113c/0x1244)
[<8068fe3c>] (tee_ioctl) from [<802892ec>] (sys_ioctl+0xe0/0xa24)
[<802892ec>] (sys_ioctl) from [<80100060>] (ret_fast_syscall+0x0/0x54)
Exception stack(0x8424ffa8 to 0x8424fff0)
ffa0: 00000000 7eb67584 00000003 8010a403 7eb67438 7eb675fc
ffc0: 00000000 7eb67584 7eb67604 00000036 7eb67448 7eb674e0 7eb67438 00000000
ffe0: 76ef7030 7eb6742c 76ee6469 76e83178
OOM killer enabled.
Restarting tasks ... done.
PM: suspend exit
sh: write error: Device or resource busy
The patch set will switch to interruptible waits and add try_to_freeze to allow the waiting
OP-TEE tasks to be frozen as well.
---
In my humble understanding without these patches OP-TEE tasks have only been frozen in user-space.
With these patches it is possible that OP-TEE tasks are frozen although the OP-TEE command
invocation didn't complete.
I'm unable to judge if there are any OP-TEE implementations relying on the fact that suspend won't
happen while the OP-TEE command invocation didn't complete.
The theoretical alternative would be to prevent that tee-supplicant is frozen first.
I was able to reproduce the issue in OP-TEE QEMU v7 using a modified version of
optee_example_secure_storage (loop around REE FS read, support multi-session).
See https://github.com/OP-TEE/optee_os/issues/4581 for details.
After applying these patches (minor adjustments of the includes) I was no longer able to
reproduce the issues.
In my tests OP-TEE QEMU v7 did suspend and resume without troubles.
I'm not able to test on other devices supporting OP-TEE.
I decided to handle each of the locations the OP-TEE task could get stuck as a separate commit.
The downside is that the above call stack doesn't really fit to any of the commits.
Christoph Gellner (3):
tee: optee: Allow to freeze the task waiting for tee-supplicant
tee: optee: Allow to freeze while waiting for call_queue
tee: optee: Allow to freeze while waiting in
OPTEE_RPC_WAIT_QUEUE_SLEEP
drivers/tee/optee/call.c | 8 +++++++-
drivers/tee/optee/rpc.c | 9 ++++++++-
drivers/tee/optee/supp.c | 3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
base-commit: c4681547bcce777daf576925a966ffa824edd09d
--
2.32.0.rc0
Hello arm-soc maintainers,
Please pull these fixes relating to OP-TEE, ftpm (firmware TPM), and
tee_bnxt_fw (Broadcom BNXT firmware manager) drivers in kexec and kdump
(emergency kexec) based workflows.
The two patches "firmware: tee_bnxt: Release TEE shm, session, and context
during kexec" and "tpm_ftpm_tee: Free and unregister TEE shared memory
during kexec" are acked by their respective maintainers.
For more details please see the description of the last patch set
https://lore.kernel.org/lkml/20210614223317.999867-1-tyhicks@linux.microsof…
Thanks,
Jens
The following changes since commit 2734d6c1b1a089fb593ef6a23d4b70903526fe0c:
Linux 5.14-rc2 (2021-07-18 14:13:49 -0700)
are available in the Git repository at:
git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/tee-kexec-fixes-for-v5.14
for you to fetch changes up to 914ab19e471d8fb535ed50dff108b0a615f3c2d8:
firmware: tee_bnxt: Release TEE shm, session, and context during kexec (2021-07-21 07:55:50 +0200)
----------------------------------------------------------------
tee: Improve support for kexec and kdump
This fixes several bugs uncovered while exercising the OP-TEE, ftpm
(firmware TPM), and tee_bnxt_fw (Broadcom BNXT firmware manager) drivers
with kexec and kdump (emergency kexec) based workflows.
----------------------------------------------------------------
Allen Pais (2):
optee: fix tee out of memory failure seen during kexec reboot
firmware: tee_bnxt: Release TEE shm, session, and context during kexec
Jens Wiklander (1):
tee: add tee_shm_alloc_kernel_buf()
Sumit Garg (1):
tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag
Tyler Hicks (4):
optee: Fix memory leak when failing to register shm pages
optee: Refuse to load the driver under the kdump kernel
optee: Clear stale cache entries during initialization
tpm_ftpm_tee: Free and unregister TEE shared memory during kexec
drivers/char/tpm/tpm_ftpm_tee.c | 8 +++---
drivers/firmware/broadcom/tee_bnxt_fw.c | 14 ++++++++---
drivers/tee/optee/call.c | 38 ++++++++++++++++++++++++++---
drivers/tee/optee/core.c | 43 ++++++++++++++++++++++++++++++++-
drivers/tee/optee/optee_private.h | 1 +
drivers/tee/optee/rpc.c | 5 ++--
drivers/tee/optee/shm_pool.c | 20 ++++++++++++---
drivers/tee/tee_shm.c | 20 ++++++++++++++-
include/linux/tee_drv.h | 2 ++
9 files changed, 132 insertions(+), 19 deletions(-)
Hi all,
This adds supports for the OP-TEE driver to communicate with secure world
using FF-A [1] as transport.
There is one change to the TEE subsystem with "tee: add sec_world_id to
struct tee_shm" to add support for holding globally unique handle assigned
by the FF-A. This is a field that I believe could useful for the AMDTEE
driver too.
For communication the OP-TEE message protocol is still used, but with a new
type of memory reference, struct optee_msg_param_fmem, to carry the
information needed by FF-A. The OP-TEE driver is refactored internally with
to sets of callbacks, one for the old SMC based communication and another
set with FF-A as transport. The functions relating to the SMC based ABI
are moved to smc_abi.c while the FF-A based ABI is added in a ffa_abi.c.
There is also a difference in how the drivers are instantiated. With the
SMC based transport we have a platform driver, module_platform_driver(),
today which we're keeping as is for this configuration. In a FF-A system we
have a FF-A driver, module_ffa_driver(), instead.
The OP-TEE driver can be compiled for both targets at the same time and
it's up to runtime configuration (device tree or ACPI) to decide how it's
initialized. Note that it's only the old SMC based driver instance that
need device tree or ACPI to initialize. The FF-A based driver relies on the
FF-A bus instead.
This can be tested QEMU
The repo for SPMC at S-EL1 retrieved by
repo init -u https://github.com/jenswi-linaro/manifest.git -m
qemu_v8.xml -b ffav4_spmc
repo sync
# Then checkout the branch optee_ffa_v3 from
# git://git.linaro.org/people/jens.wiklander/linux-tee.git
# in the linux directory
To build do:
cd build
make toolchains
make all
To boot:
make run-only
Test with xtest, perhaps only with the command "xtest 1004" in case you're
not interested in too many tests.
Thanks,
Jens
[1] https://developer.arm.com/documentation/den0077/latest
v2->v3:
- Rebased on 5.14-rc2 which now have the FF-A patches merged
- Fixed a couple bugs in optee_shm_register() and optee_shm_unregister()
which where introduced in "optee: refactor driver with internal callbacks"
in previous the version.
- Separated SMC ABI specifics into smc_abi.c to keep it separated from
the FF-A ABI functions as requested by Sumit.
- Added the FF-A specifics in ffa_abi.c
- Provided an implementation for optee_ffa_remove()
v1->v2:
- Rebased to the FF-A v7 patch
- Fixed a couple of reports from kernel test robot <lkp(a)intel.com>
Jens Wiklander (5):
tee: add sec_world_id to struct tee_shm
optee: simplify optee_release()
optee: refactor driver with internal callbacks
optee: isolate smc abi
optee: add FF-A support
drivers/tee/optee/Makefile | 7 +-
drivers/tee/optee/call.c | 415 ++-------
drivers/tee/optee/core.c | 673 ++-------------
drivers/tee/optee/ffa_abi.c | 910 ++++++++++++++++++++
drivers/tee/optee/optee_ffa.h | 153 ++++
drivers/tee/optee/optee_msg.h | 27 +-
drivers/tee/optee/optee_private.h | 155 +++-
drivers/tee/optee/rpc.c | 270 +-----
drivers/tee/optee/shm_pool.c | 89 --
drivers/tee/optee/shm_pool.h | 14 -
drivers/tee/optee/smc_abi.c | 1301 +++++++++++++++++++++++++++++
include/linux/tee_drv.h | 7 +-
12 files changed, 2650 insertions(+), 1371 deletions(-)
create mode 100644 drivers/tee/optee/ffa_abi.c
create mode 100644 drivers/tee/optee/optee_ffa.h
delete mode 100644 drivers/tee/optee/shm_pool.c
delete mode 100644 drivers/tee/optee/shm_pool.h
create mode 100644 drivers/tee/optee/smc_abi.c
--
2.31.1
Hi,
LOC (Linaro OP-TEE Contribution) monthly meeting is planned to take place
on Thursday July22(a)17.00 (UTC+2).
Looking for topics from people. If you have anything you'd like to discuss,
please let us know.
Meeting details:
---------------
Date/time: Thursday Jul22(a)17.00 (UTC+2)
https://everytimezone.com/s/d926310d
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Regards,
Ruchika on behalf of the Linaro OP-TEE team
Dear. Linaro
hello! my name is Hojin-Choi from Korea Univ in Korea
I have a question about optee
currently werun optee with virtual machine. Although we modify 'Makefile' in 'build' folder for changing cortex a-15 to cortex-a9 in optee, it give error message which "cortex-a9's support machines 'xilinx-zynq-a9, vexpress-a9, realview-pbx-a9, sabrelite' do not support secure". How can we fix the error or any other methods to run cortex-a9 with trustzone?
best.
v5:
- Picked up Reviewed-by's from Jens.
- Added 'Cc: stable(a)vger.kernel.org' to all commits as this is intended
to be a bug fix series. I'm happy to sort out backports with the
stable team.
- Got rid of the bool is_mapped parameter of optee_disable_shm_cache()
by abstracting out the function with two wrappers. One
(optee_disable_shm_cache()) for normal case where the shm cache is
fully mapped and another (optee_disable_unmapped_shm_cache()) for the
unusual case of the shm cache having potentially invalid entries.
- Replaced my previous 'tee: Support kernel shm registration without
dma-buf' patch with a cleaner implementation ('tee: Correct
inappropriate usage of TEE_SHM_DMA_BUF flag') from Sumit Garg.
v4: https://lore.kernel.org/lkml/20210610210913.536081-1-tyhicks@linux.microsof…
v3: https://lore.kernel.org/lkml/20210609002326.210024-1-tyhicks@linux.microsof…
v2: https://lore.kernel.org/lkml/20210225090610.242623-1-allen.lkml@gmail.com/
v1: https://lore.kernel.org/lkml/20210217092714.121297-1-allen.lkml@gmail.com/
This series fixes several bugs uncovered while exercising the OP-TEE
(Open Portable Trusted Execution Environment), ftpm (firmware TPM), and
tee_bnxt_fw (Broadcom BNXT firmware manager) drivers with kexec and
kdump (emergency kexec) based workflows.
The majority of the problems are caused by missing .shutdown hooks in
the drivers. The .shutdown hooks are used by the normal kexec code path
to let the drivers clean up prior to executing the target kernel. The
.remove hooks, which are already implemented in these drivers, are not
called as part of the kexec code path. This resulted in shared memory
regions, that were cached and/or registered with OP-TEE, not being
cleared/unregistered prior to kexec. The new kernel would then run into
problems when handling the previously cached virtual addresses or trying
to register newly allocated shared memory objects that overlapped with
the previously registered virtual addresses. The TEE didn't receive
notification that the old virtual addresses were no longer meaningful
and that a new kernel, with a new address space, would soon be running.
However, implementing .shutdown hooks was not enough for supporting
kexec. There was an additional problem caused by the TEE driver's
reliance on the dma-buf subsystem for multi-page shared memory objects
that were registered with the TEE. Shared memory objects backed by a
dma-buf use a different mechanism for reference counting. When the final
reference is released, work is scheduled to be executed to unregister
the shared memory with the TEE but that work is only completed prior to
the current task returning the userspace. In the case of a kexec
operation, the current task that's calling the driver .shutdown hooks
never returns to userspace prior to the kexec operation so the shared
memory was never unregistered. This eventually caused problems from
overlapping shared memory regions that were registered with the TEE
after several kexec operations. The large 4M contiguous region
allocated by the tee_bnxt_fw driver reliably ran into this issue on the
fourth kexec on a system with 8G of RAM.
The use of dma-buf makes sense for shared memory that's in use by
userspace but dma-buf's aren't needed for shared memory that will only
used by the driver. This series separates dma-buf backed shared memory
allocated by the kernel from multi-page shared memory that the kernel
simply needs registered with the TEE for private use.
One other noteworthy change in this series is to completely refuse to
load the OP-TEE driver in the kdump kernel. This is needed because the
secure world may have had all of its threads in suspended state when the
regular kernel crashed. The kdump kernel would then hang during boot
because the OP-TEE driver's .probe function would attempt to use a
secure world thread when they're all in suspended state. Another problem
is that shared memory allocations could fail under the kdump kernel
because the previously registered were not unregistered (the .shutdown
hook is not called when kexec'ing into the kdump kernel).
The first patch in the series fixes potential memory leaks that are not
directly related to kexec or kdump but were noticed during the
development of this series.
Tyler
Allen Pais (2):
optee: fix tee out of memory failure seen during kexec reboot
firmware: tee_bnxt: Release TEE shm, session, and context during kexec
Jens Wiklander (1):
tee: add tee_shm_alloc_kernel_buf()
Sumit Garg (1):
tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag
Tyler Hicks (4):
optee: Fix memory leak when failing to register shm pages
optee: Refuse to load the driver under the kdump kernel
optee: Clear stale cache entries during initialization
tpm_ftpm_tee: Free and unregister TEE shared memory during kexec
drivers/char/tpm/tpm_ftpm_tee.c | 8 ++---
drivers/firmware/broadcom/tee_bnxt_fw.c | 14 ++++++--
drivers/tee/optee/call.c | 38 +++++++++++++++++++---
drivers/tee/optee/core.c | 43 ++++++++++++++++++++++++-
drivers/tee/optee/optee_private.h | 1 +
drivers/tee/optee/rpc.c | 5 +--
drivers/tee/optee/shm_pool.c | 20 +++++++++---
drivers/tee/tee_shm.c | 20 +++++++++++-
include/linux/tee_drv.h | 2 ++
9 files changed, 132 insertions(+), 19 deletions(-)
--
2.25.1
Hello Sudeep and all,
On Wed, 7 Jul 2021 at 19:52, Sudeep Holla <sudeep.holla(a)arm.com> wrote:
>
> Hi Sumit,
>
> I was holding off you reply as I didn't have all the background on this.
> Achin did mention that this is preparatory work for FFA notifications.
> I did mention to him that this is more than that, it is custom extension
> to address what FF-A notification is trying to in standard way.
>
> I share same opinion as Marc Z.
>
> On Wed, Jul 07, 2021 at 11:22:23AM +0530, Sumit Garg wrote:
> > On Tue, 6 Jul 2021 at 18:16, Marc Zyngier <maz(a)kernel.org> wrote:
>
> [...]
>
> > >
> > > I don't care about OP-TEE. If you are proposing a contract between S
> > > and NS, it has to be TEE and OS independent. That's how the
> > > architecture works.
> > >
> >
> > Agree, here we are not proposing a common contract among the S and NS
> > world that every TEE (based on Arm TrustZone) will use to communicate
> > with REE (Linux in our case) but rather an OP-TEE specific
> > notifications feature that is built on top of OP-TEE specific ABIs.
> >
> > And I can see your arguments coming from an FFA perspective but there
> > are platforms like the ones based on Armv7 which don't support FFA
> > ABI. Maybe Jens can elaborate how this feature will fit in when FFA
> > comes into picture?
> >
>
> I can understand that but won't those platforms add the support both in
> the kernel(current series) and secure world to address notifications.
> While you could argue that it is small extension to what is already present
> but I prefer they support FF-A is they need such a support instead of adding
> custom mechanisms. It is hard to maintain and each vendor will deviate
> from this custom mechanism and soon we will have bunch of them to handle.
There exist armv7-a platforms that expect OP-TEE notification support and will not move the FF-A, like the stm32mp15. This platform won't move to FF-A mainly due to the memory cost of the added SPM layer and the device physical constraints.
We have a usecase for OP-TEE notification. We're working on the integration of an SCMI server in OP-TEE. SCMI notification is a feature needed is this scope and it requires OP-TEE async notification means as those proposed here.
This OP-TEE async notif also brings a lot of value in OP-TEE as it allows a OP-TEE secure thread (i.e. executing a trusted application service) to gently wait on a secure interrupt (as a slow bus transaction completion or many other usecase) with the CPU relaxed. This support is provided by the proposed series. I believe existing device should be able to leverage this OP-TEE feature without needing their OP-TEE to move to the new FF-A interface.
Regards,
Etienne
>
> [...]
ST Restricted
Hi all,
This adds supports for the OP-TEE driver to communicate with secure world
using FF-A [1] as transport.
These patches are based on the FF-A v7 patch set by Sudeep Holla [2] [3].
There is one change to the TEE subsystem with "tee: add sec_world_id to
struct tee_shm" to add support for holding globally unique handle assigned
by the FF-A. This is a field that I believe could useful for the AMDTEE
driver too.
For communication the OP-TEE message protocol is still used, but with a new
type of memory reference, struct optee_msg_param_fmem, to carry the
information needed by FF-A. The OP-TEE driver is refactored internally with
to sets of callbacks, one for the old SMC based communication and another
set with FF-A as transport.
There is also a difference in how the drivers are instantiated. With the
SMC based transport we have a platform driver, module_platform_driver(),
today which we're keeping as is for this configuration. In a FF-A system we
have a FF-A driver, module_ffa_driver(), instead.
The OP-TEE driver can be compiled for both targets at the same time and
it's up to runtime configuration (device tree or ACPI) to decide how it's
initialized.
Thanks,
Jens
[1] https://developer.arm.com/documentation/den0077/latest
[2] https://lore.kernel.org/linux-arm-kernel/20210521151033.181846-1-sudeep.hol…
[3] git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git v5.13/ffa
v1->v2:
- Rebased to the FF-A v7 patch
- Fixed a couple of reports from kernel test robot <lkp(a)intel.com>
Jens Wiklander (5):
tee: add sec_world_id to struct tee_shm
optee: simplify optee_release()
optee: refactor driver with internal callbacks
optee: add a FF-A memory pool
optee: add FF-A support
drivers/tee/optee/call.c | 325 +++++++++++---
drivers/tee/optee/core.c | 689 ++++++++++++++++++++++++++----
drivers/tee/optee/optee_ffa.h | 153 +++++++
drivers/tee/optee/optee_msg.h | 27 +-
drivers/tee/optee/optee_private.h | 88 +++-
drivers/tee/optee/rpc.c | 137 +++++-
drivers/tee/optee/shm_pool.c | 65 ++-
drivers/tee/optee/shm_pool.h | 1 +
include/linux/tee_drv.h | 7 +-
9 files changed, 1326 insertions(+), 166 deletions(-)
create mode 100644 drivers/tee/optee/optee_ffa.h
--
2.25.1
Greetings,
I’m Rafael Gameiro, and I’m currently doing my Thesis in Msc Computer
Science course of FCT NOVA University of Lisbon.
As the subject suggests, I have come across a presentation Linaro did some
years ago [1]. In my thesis, I have been trying to create an attestation
ta, that generates an attestation proof of a set of components created by
me. To ensure trustability over this attestation service, I thought I could
use this SKS to possibly generate a keypair, and perform the sign operation
that I need to generate the attestation proof.
I searched for this SKS on OP-TEE OS [2], OP-TEE Client [3], and OP-TEE
Tests[4], but I did not found any TA that explicitly said it was the SKS
that was referred in the said presentation. The only possible comparisons I
found were the TEE_AsymmetricSignDigest etc functions, derived from GP
internal API, and the TA PKCS#11.
My Question is, does this SKS still exists, and if yes, where could I find
it.
If not, does one of the above mentioned libraries is a SKS "replacement"?
If yes, which one?
Thank you for your time.
Best regards,
Rafael Gameiro
[1]
https://pt.slideshare.net/linaroorg/hkg18402-build-secure-key-management-se…
[2] https://github.com/OP-TEE/optee_os
[3] https://github.com/OP-TEE/optee_client
[4] https://github.com/OP-TEE/optee_test
When the system is going to hibernate or suspend it might happen
that the tee-supplicant task is frozen first.
In this case a running OP-TEE task might get stuck in the loop using
wait_for_completion_interruptible to wait for response of tee-supplicant.
As a consequence other OP-TEE tasks waiting for the above or a
succeeding stuck OP-TEE task might get stuck as well
- waiting for call queue entry to be completed
- waiting for OPTEE_RPC_WAIT_QUEUE_WAKEUP
This will result in the tasks "refusing to freeze" and
the hibernate or suspend will fail.
OP-TEE issue: https://github.com/OP-TEE/optee_os/issues/4581
- Read back the object
PM: suspend entry (s2idle)
Filesystems sync: 0.000 seconds
Freezing user space processes ...
Freezing of tasks failed after 20.008 seconds (3 tasks refusing to freeze, wq_busy=0):
task:optee_example_s state:R running task stack: 0 pid: 124 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<841c4000>] (0x841c4000)
task:optee_example_s state:D stack: 0 pid: 126 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120)
[<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340)
[<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc)
[<807d56a0>] (wait_for_completion) from [<80692134>] (optee_cq_wait_for_completion+0x14/0x60)
[<80692134>] (optee_cq_wait_for_completion) from [<806924dc>] (optee_do_call_with_arg+0x14c/0x154)
[<806924dc>] (optee_do_call_with_arg) from [<80692edc>] (optee_shm_unregister+0x78/0xcc)
[<80692edc>] (optee_shm_unregister) from [<80690a9c>] (tee_shm_release+0x88/0x174)
[<80690a9c>] (tee_shm_release) from [<8057f89c>] (dma_buf_release+0x44/0xb0)
[<8057f89c>] (dma_buf_release) from [<8028e4e8>] (__dentry_kill+0x110/0x17c)
[<8028e4e8>] (__dentry_kill) from [<80276cfc>] (__fput+0xc0/0x234)
[<80276cfc>] (__fput) from [<80140b1c>] (task_work_run+0x90/0xbc)
[<80140b1c>] (task_work_run) from [<8010b1c8>] (do_work_pending+0x4a0/0x5a0)
[<8010b1c8>] (do_work_pending) from [<801000cc>] (slow_work_pending+0xc/0x20)
Exception stack(0x843f5fb0 to 0x843f5ff8)
5fa0: 00000000 7ef63448 fffffffe 00000000
5fc0: 7ef63448 76f163b0 7ef63448 00000006 7ef63448 7ef634e0 7ef63438 00000000
5fe0: 00000006 7ef63400 76e74833 76dff856 800e0130 00000004
task:optee_example_s state:D stack: 0 pid: 128 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120)
[<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340)
[<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc)
[<807d56a0>] (wait_for_completion) from [<8069359c>] (optee_handle_rpc+0x554/0x710)
[<8069359c>] (optee_handle_rpc) from [<806924cc>] (optee_do_call_with_arg+0x13c/0x154)
[<806924cc>] (optee_do_call_with_arg) from [<80692910>] (optee_invoke_func+0x110/0x190)
[<80692910>] (optee_invoke_func) from [<8068fe3c>] (tee_ioctl+0x113c/0x1244)
[<8068fe3c>] (tee_ioctl) from [<802892ec>] (sys_ioctl+0xe0/0xa24)
[<802892ec>] (sys_ioctl) from [<80100060>] (ret_fast_syscall+0x0/0x54)
Exception stack(0x8424ffa8 to 0x8424fff0)
ffa0: 00000000 7eb67584 00000003 8010a403 7eb67438 7eb675fc
ffc0: 00000000 7eb67584 7eb67604 00000036 7eb67448 7eb674e0 7eb67438 00000000
ffe0: 76ef7030 7eb6742c 76ee6469 76e83178
OOM killer enabled.
Restarting tasks ... done.
PM: suspend exit
sh: write error: Device or resource busy
The patch set will switch to interruptible waits and add try_to_freeze to allow the waiting
OP-TEE tasks to be frozen as well.
---
In my humble understanding without these patches OP-TEE tasks have only been frozen in user-space.
With these patches it is possible that OP-TEE tasks are frozen although the OP-TEE command
invocation didn't complete.
I'm unable to judge if there are any OP-TEE implementations relying on the fact that suspend won't
happen while the OP-TEE command invocation didn't complete.
The theoretical alternative would be to prevent that tee-supplicant is frozen first.
I was able to reproduce the issue in OP-TEE QEMU v7 using a modified version of
optee_example_secure_storage (loop around REE FS read, support multi-session).
See https://github.com/OP-TEE/optee_os/issues/4581 for details.
After applying these patches (minor adjustments of the includes) I was no longer able to
reproduce the issues.
In my tests OP-TEE QEMU v7 did suspend and resume without troubles.
I'm not able to test on other devices supporting OP-TEE.
I decided to handle each of the locations the OP-TEE task could get stuck as a separate commit.
The downside is that the above call stack doesn't really fit to any of the commits.
Christoph Gellner (3):
tee: optee: Allow to freeze the task waiting for tee-supplicant
tee: optee: Allow to freeze while waiting for call_queue
tee: optee: Allow to freeze while waiting in
OPTEE_RPC_WAIT_QUEUE_SLEEP
drivers/tee/optee/call.c | 8 +++++++-
drivers/tee/optee/rpc.c | 9 ++++++++-
drivers/tee/optee/supp.c | 3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
base-commit: c4681547bcce777daf576925a966ffa824edd09d
--
2.32.0.rc0
[CC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.14.0 is scheduled to be released on 2021-07-16. 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/4704.
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,
--
Jerome
Hi all,
This adds support for asynchronous notifications from OP-TEE in secure
world to the OP-TEE driver. This allows a design with a top half and bottom
half type of driver where the top half runs in secure interrupt context and
a notifications tells normal world to schedule a yielding call to do the
bottom half processing.
An interrupt is used to notify the driver that there are asynchronous
notifications pending.
v2:
* Added documentation
* Converted optee bindings to json-schema and added interrupt property
* Configure notification interrupt from DT instead of getting it
from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>.
Thanks,
Jens
Jens Wiklander (7):
docs: staging/tee.rst: add a section on OP-TEE notifications
dt-bindings: arm: Convert optee binding to json-schema
dt-bindings: arm: optee: add interrupt property
tee: fix put order in teedev_close_context()
tee: add tee_dev_open_helper() primitive
optee: separate notification functions
optee: add asynchronous notifications
.../bindings/arm/firmware/linaro,optee-tz.txt | 31 ---
.../arm/firmware/linaro,optee-tz.yaml | 57 +++++
Documentation/staging/tee.rst | 27 +++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/call.c | 27 +++
drivers/tee/optee/core.c | 87 +++++--
drivers/tee/optee/notif.c | 226 ++++++++++++++++++
drivers/tee/optee/optee_msg.h | 9 +
drivers/tee/optee/optee_private.h | 23 +-
drivers/tee/optee/optee_rpc_cmd.h | 31 +--
drivers/tee/optee/optee_smc.h | 75 +++++-
drivers/tee/optee/rpc.c | 73 +-----
drivers/tee/tee_core.c | 37 ++-
include/linux/tee_drv.h | 27 +++
14 files changed, 576 insertions(+), 155 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
create mode 100644 drivers/tee/optee/notif.c
--
2.31.1