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 series also adds some TEE features like:
Patch #1, #2 enables support for registered kernel shared memory with TEE.
Patch #3 enables support for private kernel login method required for
cases like trusted keys where we don't wan't user-space to directly access
TEE service to retrieve trusted key contents.
Rest of the patches from #4 to #7 adds support for TEE based trusted keys.
This patch-set has been tested with OP-TEE based pseudo TA which can be
found here [1].
Looking forward to your valuable feedback/suggestions.
[1] https://github.com/OP-TEE/optee_os/pull/3082
Sumit Garg (7):
tee: optee: allow kernel pages to register as shm
tee: enable support to register kernel memory
tee: add private login method for kernel clients
KEYS: trusted: Introduce TEE based Trusted Keys
KEYS: encrypted: Allow TEE based trusted master keys
doc: keys: Document usage of TEE based Trusted Keys
MAINTAINERS: Add entry for TEE based Trusted Keys
Documentation/security/keys/tee-trusted.rst | 93 +++++
MAINTAINERS | 9 +
drivers/tee/optee/call.c | 7 +
drivers/tee/tee_core.c | 6 +
drivers/tee/tee_shm.c | 16 +-
include/keys/tee_trusted.h | 84 ++++
include/keys/trusted-type.h | 1 +
include/linux/tee_drv.h | 1 +
include/uapi/linux/tee.h | 2 +
security/keys/Kconfig | 3 +
security/keys/Makefile | 3 +
security/keys/encrypted-keys/masterkey_trusted.c | 10 +-
security/keys/tee_trusted.c | 506 +++++++++++++++++++++++
13 files changed, 737 insertions(+), 4 deletions(-)
create mode 100644 Documentation/security/keys/tee-trusted.rst
create mode 100644 include/keys/tee_trusted.h
create mode 100644 security/keys/tee_trusted.c
--
2.7.4
If the kernel is compiled with CONFIG_PREEMPT_VOLUNTARY and OP-TEE is
executing a long running workload, the following errors are raised:
[ 1705.971228] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 1705.977195] rcu: (detected by 0, t=2102 jiffies, g=51977, q=3)
[ 1705.983152] rcu: All QSes seen, last rcu_sched kthread activity 2102 (140596-138494), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 1705.994729] optee-xtest R running task 0 169 157 0x00000002
While OP-TEE is returning regulary to the kernel due to timer
interrrupts, the OPTEE_SMC_FUNC_FOREIGN_INTR case does not contain an
explicit rescheduling point. Add a might_sleep() to the RPC request case
to ensure that the kernel can reschedule another task if OP-TEE requests
RPC handling.
Signed-off-by: Rouven Czerwinski <r.czerwinski(a)pengutronix.de>
---
drivers/tee/optee/call.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index aa942703ae65..13b0269a0abc 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -148,6 +148,7 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg)
*/
optee_cq_wait_for_completion(&optee->call_queue, &w);
} else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) {
+ might_sleep();
param.a0 = res.a0;
param.a1 = res.a1;
param.a2 = res.a2;
--
2.20.1
[Sent to all e-mail addresses found in optee_os/MAINTAINERS]
Dear OP-TEE users and contributors,
FYI, the next OP-TEE release (3.6.0) is scheduled for the end of next week
(July 4th) and I plan to create the -rc1 tag next Monday. In the meantime,
please update your pending pull requests, help review patches on GitHub,
run some tests on master etc.
I will let you know when the -rc1 tag is ready for testing, at which point
I will collect Tested-by tags in pull request #3099 [1], and merge only bug
fixes into master.
Thanks for your continued help and support!
[2] https://github.com/OP-TEE/optee_os/pull/3099
Regards,
--
Jerome
Hello community,
This is the next version of OP-TEE support series.
In case of any issues with mail (Julien Grall had some troubles with =20
sequences in the patches, thanks to our corporate Exchange, I assume),
this series can be pulled from [4].
Note: I deliberately removed Jan Beulich from CC list, because he
explicitly indicated that he is not interested in this series ([5]).
List of changes is below. More specific changes are described along
with the corresponding patches.
===
v5:
- Series rebased to staging branch instead of master one.
- OP-TEE protocol headers was taken from OP-TEE tree instead of
Linux one
- Added acked-by tags
- Fixed (and tested) issue when XEN would not boot if it is build
with CONFIG_TEE=n
====
v4:
- Substantial rework of OP-TEE mediator. Now it tries to return meaningful
error codes back to the guest.
- OP-TEE mediator does not use struct cpu_user_regs as a storage for
parameters and return values when calling OP-TEE. This makes it
compatbile with requirement from SMCCC.
- tee=native option replaced with tee=optee
- Authorship and s-o-b tag reset to my EPAM mail address
====
v3:
- Patch "arm: add tee_enabled flag to xen_arch_domainconfig" was
squashed into "xen/arm: add generic TEE mediator framework"
- I implemented more elaborate error repoting to a guest. Now guest
will get meaningful error codes instead of generic
ARM_SMCCC_ERR_UNKNOWN_FUNCTION.
====
v2:
- Use domain flags insted of domctl interface to enable optee for guests
- Remove patch "libxc: add xc_dom_tee_enable(...) function" because
of previous change
- Mediator now stores own context in arch part of struct domain, so
I removed patch "optee: add domain contexts"
Per-patch changes are described in corresponding emails.
====
v2:
This is v2 of patch series for OP-TEE mediator support in XEN. Changes from v1:
- Added domctl interface, so now xl decides what domain should work with TEE
- Removed XSM support due to change described above
- Patch with OP-TEE mediator was splited to 7 separate patches
- Removed patch with call_smccc() function. Now this series depend on
Julien Grall's series "xen/arm: SMCCC fixup and improvement" [3]
=====
v1:
This is follow for patch series [1]. There was lots of discussions
for that series and I tried to address all of them in this new patchset.
Currently, I had a working solution for OP-TEE virtualization and it is being
upstreamed right now ([2]). So, I think it is a good time to introduce support
in XEN as well.
This series include generic TEE mediator framework and full-scale OP-TEE mediator
which is working with mentioned chages in OP-TEE. So, multiple domains can
work simultaneously with OP-TEE.
I added XSM support, so now it is possible to control which domains can work
with TEEs. Also I changed way how TEE discovery is done. Now it is very
generic and should support any platform.
[1] https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg01451.html
[2] https://github.com/OP-TEE/optee_os/pull/2370
[3] https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02138.html
[4] https://github.com/lorc/xen/tree/optee_v6
[5] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01805.html
Volodymyr Babchuk (10):
xen/arm: add generic TEE mediator framework
xen/arm: optee: add OP-TEE header files
xen/arm: optee: add OP-TEE mediator skeleton
xen/arm: optee: add fast calls handling
xen/arm: optee: add std call handling
xen/arm: optee: add support for RPC SHM buffers
xen/arm: optee: add support for arbitrary shared memory
xen/arm: optee: add support for RPC commands
tools/arm: tee: add "tee" option for xl.cfg
tools/arm: optee: create optee firmware node in DT if tee=optee
MAINTAINERS | 6 +
docs/man/xl.cfg.5.pod.in | 21 +
tools/libxl/libxl.h | 5 +
tools/libxl/libxl_arm.c | 42 +
tools/libxl/libxl_types.idl | 6 +
tools/xl/xl_parse.c | 9 +
xen/arch/arm/Kconfig | 9 +
xen/arch/arm/Makefile | 1 +
xen/arch/arm/domain.c | 19 +
xen/arch/arm/setup.c | 2 +
xen/arch/arm/tee/Kconfig | 4 +
xen/arch/arm/tee/Makefile | 2 +
xen/arch/arm/tee/optee.c | 1540 +++++++++++++++++++++++
xen/arch/arm/tee/tee.c | 98 ++
xen/arch/arm/vsmc.c | 5 +
xen/arch/arm/xen.lds.S | 7 +
xen/include/asm-arm/domain.h | 4 +
xen/include/asm-arm/tee/optee_msg.h | 310 +++++
xen/include/asm-arm/tee/optee_rpc_cmd.h | 318 +++++
xen/include/asm-arm/tee/optee_smc.h | 564 +++++++++
xen/include/asm-arm/tee/tee.h | 112 ++
xen/include/public/arch-arm.h | 6 +
22 files changed, 3090 insertions(+)
create mode 100644 xen/arch/arm/tee/Kconfig
create mode 100644 xen/arch/arm/tee/Makefile
create mode 100644 xen/arch/arm/tee/optee.c
create mode 100644 xen/arch/arm/tee/tee.c
create mode 100644 xen/include/asm-arm/tee/optee_msg.h
create mode 100644 xen/include/asm-arm/tee/optee_rpc_cmd.h
create mode 100644 xen/include/asm-arm/tee/optee_smc.h
create mode 100644 xen/include/asm-arm/tee/tee.h
--
2.21.0
Hi
A number of people are getting interested in developing trusted applications for TEEs (not just for OPTEE) and they want to understand the development and technical challenges that will be encountered. They're looking for technical foresight. I thought we could draw on our OPTEE expertise and look to whether we can develop insights applicable across all TEEs.
Practical information about limitations may provide insights.
It's a broad question and I don't want to limit the scope to the following list, but here's some guidance on possible key technical factors causing limitations to arise:
- Memory footprint.
o What's the impact both for volatile and non-volatile?
- Code size.
o This is a massive issue for the IoT space, less so for edge devices. Does aarch64 v aarch32 have a big impact? How big? What other factors.
- Portability.
- Software Stack
o UEFI/BIOS support for security?
o TEE software update mechanism?
o Convergence on a standardized bootchain?
o Adoption/deployment of Global Platform interface?
o Bootloader impact (generally), ATF, u-boot, kernel.
- Toolchain support/Developing in languages other than C.
o I know OPTEE doesn't support C++. Why? Is there partial support?
o I read somewhere GOlang has aarch64 issues for normal world OS.
- Normal World OS interworking.
o Any standardisation of interfacing to a tee?
- Certification/Testing.
o Is there a standard toolchain for conformance testing?
- Device support.
o TPMs.
o eSims.
- Anything else?
Best
Simon
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.