From: Volodymyr Babchuk <vlad.babchuk(a)gmail.com>
Hello all,
Sorry for late submussion. I was busy with other projects.
Global 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 (11):
arm: add generic TEE mediator framework
arm: add tee_enabled flag to xen_arch_domainconfig
arm: tee: add OP-TEE header files
optee: add OP-TEE mediator skeleton
optee: add fast calls handling
optee: add std call handling
optee: add support for RPC SHM buffers
optee: add support for arbitrary shared memory
optee: add support for RPC commands
xl: add "tee" option for xl.cfg
libxl: arm: create optee firmware node in DT if tee=1
MAINTAINERS | 6 +
docs/man/xl.cfg.pod.5.in | 10 +
tools/libxl/libxl_arm.c | 31 +
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_parse.c | 1 +
xen/arch/arm/Kconfig | 9 +
xen/arch/arm/Makefile | 1 +
xen/arch/arm/domain.c | 8 +
xen/arch/arm/domain_build.c | 4 +
xen/arch/arm/domctl.c | 1 +
xen/arch/arm/setup.c | 1 +
xen/arch/arm/shutdown.c | 1 +
xen/arch/arm/tee/Kconfig | 4 +
xen/arch/arm/tee/Makefile | 2 +
xen/arch/arm/tee/optee.c | 1054 +++++++++++++++++++++++++++
xen/arch/arm/tee/tee.c | 69 ++
xen/arch/arm/vsmc.c | 5 +
xen/arch/arm/xen.lds.S | 7 +
xen/include/asm-arm/domain.h | 3 +
xen/include/asm-arm/tee/optee_msg.h | 444 +++++++++++
xen/include/asm-arm/tee/optee_smc.h | 507 +++++++++++++
xen/include/asm-arm/tee/tee.h | 91 +++
xen/include/public/arch-arm.h | 3 +
24 files changed, 2264 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.20.0
+ tee-dev ML
On Tue, 12 Feb 2019 at 17:36, Alexander Graf <agraf(a)suse.de> wrote:
>
> On 02/12/2019 12:34 PM, Heinrich Schuchardt wrote:
> > On 2/12/19 10:49 AM, Alexander Graf wrote:
> >> On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
> >>> Hello Alex, hello Takahiro,
> >>>
> >>> this morning I met Daniel Thompson of Linaro. He thinks it would be
> >>> quite valuable if U-Boot would at least offer read access to EFI
> >>> variables at runtime.
> >>>
> >>> I think what it takes is only a RAM buffer that we put between our
> >>> current storage backend (i.e. synchronization with U-Boot variables)
> >>> and the API implementation.
> >>>
> >>> We will need such a buffer anyway for non-permanent variables once we
> >>> have a SPI flash storage.
> >> I think slowly we need to take a critical design decision: Do we want to
> >> be in the business of managing runtime UEFI variables?
> >>
> >> I don't have a fully cohesive answer to that yet. My gut feeling tells
> >> me, that runtime variables would be much better off if they lived in
> >> TrustZone. That way we don't have to play relocation tricks, and devices
> >> that give you persistency are owned by the secure world anyway, so there
> >> is no weird intersection between OS and RTS.
> >>
> >> So maybe the path forward would be to implement variable services in ATF
> >> (or OP-TEE rather I suppose) and just provide shim stubs to communicate
> >> with them from runtime services? That would keep all the variable logic
> >> platform agnostic, and we would not have to jump through weird hoops
> >> with DM.
> > U-Boot' major asset are the many boards supported by drivers. Does ATF
> > or OP-TEE have drivers for SPI?
> >
> > Or is your idea that U-Boot would provide a module that is set up as a
> > trusted driver or trusted app, cf.
> > https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-o…
>
> I think it's perfectly possible to build a special OP-TEE U-Boot target
> that can then reuse its drivers, similar to Simon's idea. But we should
> probably not try to target RTS with that, but only secure enclaves.
>
One of OP-TEE design goals [1] being:
Small footprint - the TEE should remain small enough to reside in a
reasonable amount of on-chip memory as found on Arm based systems.
I think this was one of main reason to have tee-supplicant
infrastructure in normal world to reuse drivers and keep small
footprint of OP-TEE.
So if we build a special OP-TEE u-boot target and link it with
optee-os as part of secure enclave then I am not sure how it will
align with above design goal.
[1] https://optee.readthedocs.io/general/about.html
-Sumit
>
> Alex
>
> _______________________________________________
> U-Boot mailing list
> U-Boot(a)lists.denx.de
> https://lists.denx.de/listinfo/u-boot
This series introduces a generic TEE bus driver concept for TEE based
kernel drivers which would like to communicate with TEE based devices/
services.
Patch #1 adds TEE bus concept where devices/services are identified via
Universally Unique Identifier (UUID) and drivers register a table of
device UUIDs which they can support. This concept also allows for device
enumeration to be specific to corresponding TEE implementation like
OP-TEE etc.
Patch #2 adds supp_nowait flag for non-blocking requests arising via
TEE internal client interface.
Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE
provides a pseudo TA to enumerate TAs which can act as devices/services
for TEE bus.
Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver.
On ARM SoC's with TrustZone enabled, peripherals like entropy sources
might not be accessible to normal world (linux in this case) and rather
accessible to secure world (OP-TEE in this case) only. So this driver
aims to provides a generic interface to OP-TEE based random number
generator service.
Example case is Developerbox based on Socionext's Synquacer SoC [1]
which provides 7 thermal sensors accessible from secure world only which
could be used as entropy sources (thermal/measurement noise).
[1] https://www.96boards.org/product/developerbox/
Changes in v6:
1. Incorporate some nitpicks in patch #1 and #3.
2. Bundle all statics in a data structure in patch #4 and use dev_*
instead of pr_*.
3. Add reviewed-by tags for patch #1, #2 and #3.
Changes in v5:
1. Add support in module device table for TEE bus devices.
2. Correct license for optee-rng module.
Changes in v4:
1. Use typedef instead of single member tee_client_device_id struct.
2. Incorporate TEE bus nitpicks.
Changes in v3:
1. Fixed bus error path in Patch #1.
2. Reversed order of Patch #2 and #3.
3. Fixed miscellaneous syntax comments and memory leak.
4. Added comments in Patch #2 for supp_nowait flag.
Changes in v2:
Based on review comments, the scope of this series has increased as
follows:
1. Added TEE bus driver framework.
2. Added OP-TEE based device enumeration.
3. Register optee-rng driver as TEE bus driver.
4. Removed DT dependency for optee-rng device UUID.
5. Added supp_nowait flag.
Sumit Garg (4):
tee: add bus driver framework for TEE based devices
tee: add supp_nowait flag in tee_context struct
tee: optee: add TEE bus device enumeration support
hwrng: add OP-TEE based rng driver
MAINTAINERS | 5 +
drivers/char/hw_random/Kconfig | 15 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/optee-rng.c | 298 +++++++++++++++++++++++++++++++++++++
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/core.c | 4 +
drivers/tee/optee/device.c | 155 +++++++++++++++++++
drivers/tee/optee/optee_private.h | 3 +
drivers/tee/optee/supp.c | 10 +-
drivers/tee/tee_core.c | 67 ++++++++-
include/linux/mod_devicetable.h | 9 ++
include/linux/tee_drv.h | 38 ++++-
scripts/mod/devicetable-offsets.c | 3 +
scripts/mod/file2alias.c | 19 +++
14 files changed, 622 insertions(+), 6 deletions(-)
create mode 100644 drivers/char/hw_random/optee-rng.c
create mode 100644 drivers/tee/optee/device.c
--
2.7.4