Hi all,
This patchset adds support for using FF-A notifications as a delivery
mechanism of asynchronous notifications from OP-TEE running in the secure
world. Support for asynchronous notifications via the SMC ABI was added in
[1], here we add the counterpart needed when using the the FF-A ABI.
Support for FF-A notifications is added with [2] and this patch set is based
on Sudeeps tree at [3].
[1] https://lore.kernel.org/lkml/20211103090255.998070-1-jens.wiklander@linaro.…
[2] https://lore.kernel.org/linux-arm-kernel/20231005-ffa_v1-1_notif-v4-0-cddd3…
[3] https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/tag/…
commit bcefd1bf63b1 ("firmware: arm_ffa: Upgrade the driver version to v1.1")
v1->v2:
* Applied Sumit's Reviewed-by
* Addressed Sumit's comment on "optee: ffa_abi: add asynchronous
notifications"
Thanks,
Jens
Jens Wiklander (2):
optee: provide optee_do_bottom_half() as a common function
optee: ffa_abi: add asynchronous notifications
drivers/tee/optee/call.c | 31 ++++++++++-
drivers/tee/optee/ffa_abi.c | 93 ++++++++++++++++++++++++++++++-
drivers/tee/optee/optee_ffa.h | 28 ++++++++--
drivers/tee/optee/optee_private.h | 9 ++-
drivers/tee/optee/smc_abi.c | 36 ++----------
5 files changed, 155 insertions(+), 42 deletions(-)
base-commit: bcefd1bf63b1ec9bb08067021cf47f0fad96f395
--
2.34.1
There is one thing I really don't understand about the offline signing process for TAs using an HSM:
In the documentation (https://link.getmailspring.com/link/4CCC8610-79B9-4890-AF1F-7A0AA56F0C20@ge…) it says to generate a keypair with openssl and sign the TAs using the public key as ${TA_SIGN_KEY}. In point 4. the usage of an HSM is described, but since it is not possible to extract the private key from an HSM, I wonder how steps 3.-5. are even possible. Do you mix the previously generated RSA key with the one from the HSM? I cannot image that is as it should be.
Can you please clarify this! Thank you
Currently supplicant dependent optee device enumeration only registers
devices whenever tee-supplicant is invoked for the first time. But it
forgets to remove devices when tee-supplicant daemon stops running and
closes its context gracefully. This leads to following error for fTPM
driver during reboot/shutdown:
[ 73.466791] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
Fix this by adding an attribute for supplicant dependent devices so that
the user-space service can detect and detach supplicant devices before
closing the supplicant:
$ for dev in /sys/bus/tee/devices/*; do if [[ -f "$dev/need_supplicant" && -f "$dev/driver/unbind" ]]; \
then echo $(basename "$dev") > $dev/driver/unbind; fi done
While at it use the global system workqueue for OP-TEE bus scanning work
rather than our own custom one.
Changes in v4:
- Changing the device name would be an ABI break, rather switch to
additional device attribute: "need_supplicant" to distinguish for ABI
compatibility.
- Dropped tested-by for patch #1, I would encourage folks to retest
this.
Changes in v3:
- Split patch into 2 separate ones, one for supplicant fix and other for
the workqueue.
Changes in v2:
- Use device names to separate out tee-supplicant dependent devices via
this patch.
- Since user-space service is aware about tee-supplicant lifespan, so
allow the user-space service to unbind tee-supplicant dependent
devices before killing the supplicant. Following command has to be
added to the tee-supplicant service file.
$ for dev in /sys/bus/tee/devices/*; do if [[ "$dev" == *"optee-ta-supp-"* ]]; \
then echo $(basename "$dev") > $dev/driver/unbind; fi done
Sumit Garg (2):
tee: optee: Fix supplicant based device enumeration
tee: optee: Remove redundant custom workqueue
.../ABI/testing/sysfs-bus-optee-devices | 9 +++++++++
drivers/tee/optee/core.c | 13 ++-----------
drivers/tee/optee/device.c | 17 +++++++++++++++--
drivers/tee/optee/optee_private.h | 2 --
4 files changed, 26 insertions(+), 15 deletions(-)
--
2.34.1
Hello arm-soc maintainers,
Please pull this OP-TEE driver fix allowing supplicant dependent devices to
be detached by user-space before the supplicant service is shut down.
Thanks,
Jens
The following changes since commit ffc253263a1375a65fa6c9f62a893e9767fbebfa:
Linux 6.6 (2023-10-29 16:31:08 -1000)
are available in the Git repository at:
git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/optee-supplicant-fix-for-v6.7
for you to fetch changes up to 7269cba53d906cf257c139d3b3a53ad272176bca:
tee: optee: Fix supplicant based device enumeration (2023-11-03 09:27:20 +0100)
----------------------------------------------------------------
OP-TEE fix for supplicant based device enumeration
Adds a sysfs attribute for devices depending on supplicant services so
that the user-space service can detect and detach those devices before
closing the supplicant
----------------------------------------------------------------
Sumit Garg (1):
tee: optee: Fix supplicant based device enumeration
Documentation/ABI/testing/sysfs-bus-optee-devices | 9 +++++++++
drivers/tee/optee/device.c | 17 +++++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
I am currently trying to sing a few TAs using the Yocto environment, namely
The three in-tree TAs shipped with optee-os
oemcrypto needed for widevine
For some reason I can't sign oemcrypto successfully using the offline singing method described in the documentation. I could however successfully exchange the default_ta.pem successfully to accomplish the above. optee-os is then built with the exchanged default private key and the oemcrypto recipe pulls this key as dependency.
This is not optimal though, since we want to use an HSM for offline signing to increase security. I am therefore suspecting that oemcrypto is somehow signed differently or that that the stripped.elf is somehow different. From what I have read, it should not matter though what you sign you TA with during the build. You can always create the digest, sign and stitch everything back together. For some reason this does not work. If I sideload the oemcrypto TA that was built by exchanging the default_ta.pem file, everything works again.
Do you have an idea what is happening here?
Hi,
This patch set optimizes OP-TEE driver private shared memory allocated as
dynamic shared memory (not from the static shared memory pool). The first
patch handles kernel private RPC allocatations larger than one page and the
second changes from alloc_pages_exact() instead of alloc_pages() for more
efficient memory usage.
v1->v2:
* Split into two patches as requested
Jens Wiklander (2):
optee: add page list to kernel private shared memory
optee: allocate shared memory with alloc_pages_exact()
drivers/tee/optee/core.c | 59 +++++++++++++++++++++++++------------
drivers/tee/optee/smc_abi.c | 45 +++++++++++++---------------
2 files changed, 61 insertions(+), 43 deletions(-)
base-commit: 05d3ef8bba77c1b5f98d941d8b2d4aeab8118ef1
--
2.34.1
We are considering to provide professional (data security) service for
TA, I think that our service software should be TA because it touches
sensitive plain text, and our software are in golang & JAVA. Does OP
TEE support golang & JAVA TA? If not, any idea of how to make it?
Best Regards
[defaultAvatar.png]
Alex
alex(a)surcloud.net
References
Visible links:
Hidden links:
2. https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&n…
This series introduces TEE system sessions for TEE service sessions that
require TEE to provision resources to prevent deadlock when clients call
the TEE.
This deadlock situation can happen when a TEE service is used by low
level system resources as for example when Linux kernel uses SCMI
service embedded in TEE for clock, reset, regulator, etc... controls.
This case is detailled in patch 2/4:
> This feature is needed to prevent a system deadlock when several TEE
> client applications invoke TEE, consuming all TEE thread contexts
> available in the secure world. The deadlock can happen in the OP-TEE
> driver for example if all these TEE threads issue an RPC call from TEE
> to Linux OS to access an eMMC RPMB partition (TEE secure storage) which
> device clock or regulator controller is accessed through an OP-TEE SCMI
> services. In that case, Linux SCMI driver must reach OP-TEE SCMI
> service without waiting until one of the consumed TEE threads is freed.
Etienne Carriere (4):
tee: optee: system call property
tee: system session
tee: optee: support tracking system threads
firmware: arm_scmi: optee: use optee system invocation
drivers/firmware/arm_scmi/optee.c | 4 +
drivers/tee/optee/call.c | 130 ++++++++++++++++++++++++++++--
drivers/tee/optee/core.c | 5 +-
drivers/tee/optee/ffa_abi.c | 14 ++--
drivers/tee/optee/optee_private.h | 29 ++++++-
drivers/tee/optee/smc_abi.c | 32 +++++---
drivers/tee/tee_core.c | 8 ++
include/linux/tee_drv.h | 16 ++++
8 files changed, 211 insertions(+), 27 deletions(-)
---
Changes since v11:
- Fixed inline description comments in patch 1/3 and 3/4, other patches
are unchanged.
Changes since v10:
- Changes patch 3/4, other are unchanged.
--
2.25.1