From: Volodymyr Babchuk <vlad.babchuk(a)gmail.com>
Hello all,
This is the 4th version of TEE mediator patch series. In the meantime
virtualization support were merged into OP-TEE mainline.
Last time our mail server changed order of messages in the mail thread.
I hope, this time it will send them in the right way. But, please pay
attention to the patch number in the subject just in case.
Overall changes from 3:
- 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.
Per-patch changes are described in corresponding emails.
Changes from 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
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=native
MAINTAINERS | 6 +
docs/man/xl.cfg.5.pod.in | 12 +
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 | 14 +
xen/arch/arm/setup.c | 8 +
xen/arch/arm/tee/Kconfig | 4 +
xen/arch/arm/tee/Makefile | 2 +
xen/arch/arm/tee/optee.c | 1395 +++++++++++++++++++++++++++
xen/arch/arm/tee/tee.c | 79 ++
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 | 444 +++++++++
xen/include/asm-arm/tee/optee_smc.h | 569 +++++++++++
xen/include/asm-arm/tee/tee.h | 106 ++
xen/include/public/arch-arm.h | 4 +
21 files changed, 2731 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_smc.h
create mode 100644 xen/include/asm-arm/tee/tee.h
--
2.21.0
Hi,
We have an ongoing action to integrate mbedtls in OP-TEE to be used in
OP-TEE core via the <crypto/crypto.h> interface.
Then there's also a library developed by NXP to take advantage of CAAM
for crypto acceleration.
The way we're dealing with different crypto algorithms today isn't
very modular. I think we can disregard the asymmetric algorithms for
now. We've already put the algorithms in different groups, hashes,
macs, ciphers (which includes modes like CBC, CTR etc), and authenc
(authenticated encryption). This was good enough for our initial
libtomcrypt integration, but I think it has been a bit painful for the
ongoing mbedtls integration. With CAAM it was solved by using an
entire new wrapper layer to work with libtomcrypt. Cedric has shown
benchmark that the new wrapping didn't cause any noticeable
degradation in performance.
To try a more fine grained modular approach I've converted the authenc
algorithms to use a struct crypto_authenc_ops internally to call the
needed functions [1]. This makes it easier to replace one
implementation with another, it's just a matter of calling the correct
crypto_aes_gcm_alloc_ctx() function for AES-GCM and the rest of the
implementation will be selected automatically. The different functions
allocating an AEC-GCM context should probably have different names
instead of using the same as in [1], but that doesn't have to be
decided right now.
With the approach in [1] applied on hashes, macs and ciphers too I
think it would be much easier to integrate any crypto library.
For paging we'll still have special interfaces to do SHA-256 or
AES-GCM, this is needed in order minimize the dependency graph for
unpaged code and also make sure that it's always callable from abort
mode (doesn't cause deadlock or whatever).
What do you think? Is this too much, too little?
Cheers,
Jens
[1] https://github.com/OP-TEE/optee_os/pull/2862