* [RFC 0/4] TEE mediator framework + OP-TEE mediator
@ 2017-10-11 19:01 Volodymyr Babchuk
2017-10-11 19:01 ` [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC Volodymyr Babchuk
` (4 more replies)
0 siblings, 5 replies; 44+ messages in thread
From: Volodymyr Babchuk @ 2017-10-11 19:01 UTC (permalink / raw)
To: Stefano Stabellini, Julien Grall, xen-devel; +Cc: Volodymyr Babchuk
Hello all,
I want to present TEE mediator, that was discussed earlier ([1]).
I selected design with built-in mediators. This is easiest way,
it removes many questions, it is easy to implement and maintain
(at least I hope so).
So, user can use Kconfig to build one or multiple mediators. During
boot, XEN will determine which TEE is running and initialize
corresponding mediator.
Framework puts a few hooks into other substems in order to be able
to work properly. It will be called during domain creation and
destruction and, obviously, to handle TEE SMCs.
Current implementation of OP-TEE mediator support only calls
from Dom0, but does this in full extent. All OP-TEE tests was
passed. I tested this on my Renesas Salvator X M3 board.
Also, I'm ready to be maintainer of this TEE mediators, if there
are no objections.
[1] https://marc.info/?l=xen-devel&m=148002191906172&w=2
Volodymyr Babchuk (4):
arm: add SMC wrapper that is compatible with SMCCC
arm: add generic TEE mediator framework
arm: tee: add OP-TEE header files
arm: tee: add basic OP-TEE mediator
MAINTAINERS | 5 +
xen/arch/arm/Kconfig | 10 +
xen/arch/arm/Makefile | 1 +
xen/arch/arm/arm32/Makefile | 1 +
xen/arch/arm/arm32/smc.S | 32 +++
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/smc.S | 29 +++
xen/arch/arm/domain.c | 7 +
xen/arch/arm/setup.c | 4 +
xen/arch/arm/tee/Kconfig | 4 +
xen/arch/arm/tee/Makefile | 2 +
xen/arch/arm/tee/optee.c | 178 ++++++++++++++++
xen/arch/arm/tee/optee_msg.h | 444 ++++++++++++++++++++++++++++++++++++++
xen/arch/arm/tee/optee_smc.h | 457 ++++++++++++++++++++++++++++++++++++++++
xen/arch/arm/tee/tee.c | 134 ++++++++++++
xen/arch/arm/vsmc.c | 5 +
xen/arch/arm/xen.lds.S | 7 +
xen/include/asm-arm/processor.h | 4 +
xen/include/asm-arm/tee.h | 79 +++++++
19 files changed, 1404 insertions(+)
create mode 100644 xen/arch/arm/arm32/smc.S
create mode 100644 xen/arch/arm/arm64/smc.S
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/optee_msg.h
create mode 100644 xen/arch/arm/tee/optee_smc.h
create mode 100644 xen/arch/arm/tee/tee.c
create mode 100644 xen/include/asm-arm/tee.h
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 44+ messages in thread* [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC 2017-10-11 19:01 [RFC 0/4] TEE mediator framework + OP-TEE mediator Volodymyr Babchuk @ 2017-10-11 19:01 ` Volodymyr Babchuk 2017-10-16 14:53 ` Julien Grall 2017-10-11 19:01 ` [RFC 2/4] arm: add generic TEE mediator framework Volodymyr Babchuk ` (3 subsequent siblings) 4 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-11 19:01 UTC (permalink / raw) To: Stefano Stabellini, Julien Grall, xen-devel Cc: Edgar E. Iglesias, Volodymyr Babchuk Existing SMC wrapper call_smc() allows only 4 parameters and returns only one value. This is enough for existing use in PSCI code, but TEE mediator will need a call that is fully compatible with ARM SMCCC. This patch adds this call for both arm32 and arm64. There was similar patch by Edgar E. Iglesias ([1]), but looks like it is abandoned. [1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html CC: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> --- xen/arch/arm/arm32/Makefile | 1 + xen/arch/arm/arm32/smc.S | 32 ++++++++++++++++++++++++++++++++ xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/smc.S | 29 +++++++++++++++++++++++++++++ xen/include/asm-arm/processor.h | 4 ++++ 5 files changed, 67 insertions(+) create mode 100644 xen/arch/arm/arm32/smc.S create mode 100644 xen/arch/arm/arm64/smc.S diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile index 0ac254f..c69f35e 100644 --- a/xen/arch/arm/arm32/Makefile +++ b/xen/arch/arm/arm32/Makefile @@ -10,4 +10,5 @@ obj-y += proc-v7.o proc-caxx.o obj-y += smpboot.o obj-y += traps.o obj-y += vfp.o +obj-y += smc.o diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S new file mode 100644 index 0000000..1cc9528 --- /dev/null +++ b/xen/arch/arm/arm32/smc.S @@ -0,0 +1,32 @@ +/* + * xen/arch/arm/arm32/smc.S + * + * Wrapper for Secure Monitors Calls + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <asm/macros.h> + +/* + * void call_smccc_smc(register_t a0, register_t a1, register_t a2, + * register_t a3, register_t a4, register_t a5, + * register_t a6, register_t a7, register_t res[4]) + */ +ENTRY(call_smccc_smc) + mov r12, sp + push {r4-r7} + ldm r12, {r4-r7} + smc #0 + pop {r4-r7} + ldr r12, [sp, #(4 * 4)] + stm r12, {r0-r3} + bx lr diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile index 718fe44..58a8ddd 100644 --- a/xen/arch/arm/arm64/Makefile +++ b/xen/arch/arm/arm64/Makefile @@ -8,6 +8,7 @@ obj-y += entry.o obj-y += insn.o obj-$(CONFIG_LIVEPATCH) += livepatch.o obj-y += smpboot.o +obj-y += smc.o obj-y += traps.o obj-y += vfp.o obj-y += vsysreg.o diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S new file mode 100644 index 0000000..aa44fba --- /dev/null +++ b/xen/arch/arm/arm64/smc.S @@ -0,0 +1,29 @@ +/* + * xen/arch/arm/arm64/smc.S + * + * Wrapper for Secure Monitors Calls + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <asm/macros.h> + +/* + * void call_smccc_smc(register_t a0, register_t a1, register_t a2, + * register_t a3, register_t a4, register_t a5, + * register_t a6, register_t a7, register_t res[4]) + */ +ENTRY(call_smccc_smc) + smc #0 + ldr x4, [sp] + stp x0, x1, [x4, 0] + stp x2, x3, [x4, 16] + ret diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h index dc6ab62..71f3e60 100644 --- a/xen/include/asm-arm/processor.h +++ b/xen/include/asm-arm/processor.h @@ -787,6 +787,10 @@ void vcpu_regs_user_to_hyp(struct vcpu *vcpu, int call_smc(register_t function_id, register_t arg0, register_t arg1, register_t arg2); +void call_smccc_smc(register_t a0, register_t a1, register_t a2, + register_t a3, register_t a4, register_t a5, + register_t a6, register_t a7, register_t res[4]); + void do_trap_hyp_serror(struct cpu_user_regs *regs); void do_trap_guest_serror(struct cpu_user_regs *regs); -- 2.7.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC 2017-10-11 19:01 ` [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC Volodymyr Babchuk @ 2017-10-16 14:53 ` Julien Grall 0 siblings, 0 replies; 44+ messages in thread From: Julien Grall @ 2017-10-16 14:53 UTC (permalink / raw) To: Volodymyr Babchuk, Stefano Stabellini, Julien Grall, xen-devel Cc: Edgar E. Iglesias Hi Volodymyr, On 11/10/17 20:01, Volodymyr Babchuk wrote: > Existing SMC wrapper call_smc() allows only 4 parameters and > returns only one value. This is enough for existing > use in PSCI code, but TEE mediator will need a call that is > fully compatible with ARM SMCCC. > This patch adds this call for both arm32 and arm64. > > There was similar patch by Edgar E. Iglesias ([1]), but looks > like it is abandoned. > > [1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html > > CC: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com> > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > xen/arch/arm/arm32/Makefile | 1 + > xen/arch/arm/arm32/smc.S | 32 ++++++++++++++++++++++++++++++++ > xen/arch/arm/arm64/Makefile | 1 + > xen/arch/arm/arm64/smc.S | 29 +++++++++++++++++++++++++++++ > xen/include/asm-arm/processor.h | 4 ++++ > 5 files changed, 67 insertions(+) > create mode 100644 xen/arch/arm/arm32/smc.S > create mode 100644 xen/arch/arm/arm64/smc.S > > diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile > index 0ac254f..c69f35e 100644 > --- a/xen/arch/arm/arm32/Makefile > +++ b/xen/arch/arm/arm32/Makefile > @@ -10,4 +10,5 @@ obj-y += proc-v7.o proc-caxx.o > obj-y += smpboot.o > obj-y += traps.o > obj-y += vfp.o > +obj-y += smc.o > > diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S > new file mode 100644 > index 0000000..1cc9528 > --- /dev/null > +++ b/xen/arch/arm/arm32/smc.S > @@ -0,0 +1,32 @@ > +/* > + * xen/arch/arm/arm32/smc.S > + * > + * Wrapper for Secure Monitors Calls > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <asm/macros.h> > + > +/* > + * void call_smccc_smc(register_t a0, register_t a1, register_t a2, > + * register_t a3, register_t a4, register_t a5, > + * register_t a6, register_t a7, register_t res[4]) > + */ > +ENTRY(call_smccc_smc) > + mov r12, sp > + push {r4-r7} > + ldm r12, {r4-r7} > + smc #0 > + pop {r4-r7} > + ldr r12, [sp, #(4 * 4)] Can we get some comment in the code to explain the hardcoded values? And maybe introduce defines? > + stm r12, {r0-r3} > + bx lr > diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile > index 718fe44..58a8ddd 100644 > --- a/xen/arch/arm/arm64/Makefile > +++ b/xen/arch/arm/arm64/Makefile > @@ -8,6 +8,7 @@ obj-y += entry.o > obj-y += insn.o > obj-$(CONFIG_LIVEPATCH) += livepatch.o > obj-y += smpboot.o > +obj-y += smc.o > obj-y += traps.o > obj-y += vfp.o > obj-y += vsysreg.o > diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S > new file mode 100644 > index 0000000..aa44fba > --- /dev/null > +++ b/xen/arch/arm/arm64/smc.S > @@ -0,0 +1,29 @@ > +/* > + * xen/arch/arm/arm64/smc.S > + * > + * Wrapper for Secure Monitors Calls > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <asm/macros.h> > + > +/* > + * void call_smccc_smc(register_t a0, register_t a1, register_t a2, > + * register_t a3, register_t a4, register_t a5, > + * register_t a6, register_t a7, register_t res[4]) > + */ > +ENTRY(call_smccc_smc) > + smc #0 > + ldr x4, [sp] > + stp x0, x1, [x4, 0] > + stp x2, x3, [x4, 16] Ditto. > + ret > diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h > index dc6ab62..71f3e60 100644 > --- a/xen/include/asm-arm/processor.h > +++ b/xen/include/asm-arm/processor.h > @@ -787,6 +787,10 @@ void vcpu_regs_user_to_hyp(struct vcpu *vcpu, > int call_smc(register_t function_id, register_t arg0, register_t arg1, > register_t arg2); > > +void call_smccc_smc(register_t a0, register_t a1, register_t a2, > + register_t a3, register_t a4, register_t a5, > + register_t a6, register_t a7, register_t res[4]); I would much prefer if you introduce a structure describing the result. This would make easier for the caller to understand what the result look like and avoid to hardcode some values in the code. So how Linux does it. > + > void do_trap_hyp_serror(struct cpu_user_regs *regs); > > void do_trap_guest_serror(struct cpu_user_regs *regs); > Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* [RFC 2/4] arm: add generic TEE mediator framework 2017-10-11 19:01 [RFC 0/4] TEE mediator framework + OP-TEE mediator Volodymyr Babchuk 2017-10-11 19:01 ` [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC Volodymyr Babchuk @ 2017-10-11 19:01 ` Volodymyr Babchuk 2017-10-16 13:00 ` Julien Grall 2017-10-11 19:01 ` [RFC 3/4] arm: tee: add OP-TEE header files Volodymyr Babchuk ` (2 subsequent siblings) 4 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-11 19:01 UTC (permalink / raw) To: Stefano Stabellini, Julien Grall, xen-devel; +Cc: Volodymyr Babchuk This patch adds basic framework for TEE mediators. Guests can't talk to TEE directly, we need some entity that will intercept request and decide what to do with them. "TEE mediaor" is a such entity. This is how it works: user can build XEN with multiple TEE mediators (see the next patches, where OP-TEE mediator is introduced). TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in the same way, as device drivers use DT_DEVICE_START()/DT_DEVICE_END() macros. In runtime, during initialization, XEN issues standard SMC to read TEE UID. Using this UID it selects and initializes one of built-in mediators. Then generic vSMC handler will call selected mediator when it intercept SMC that belongs to TEE OS or TEE application. Also, there are hooks for domain construction and destruction, so TEE mediator can inform TEE about VM lifecycle. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> --- MAINTAINERS | 5 ++ xen/arch/arm/Kconfig | 10 ++++ xen/arch/arm/Makefile | 1 + xen/arch/arm/domain.c | 7 +++ xen/arch/arm/setup.c | 4 ++ xen/arch/arm/tee/Kconfig | 0 xen/arch/arm/tee/Makefile | 1 + xen/arch/arm/tee/tee.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++ xen/arch/arm/vsmc.c | 5 ++ xen/arch/arm/xen.lds.S | 7 +++ xen/include/asm-arm/tee.h | 79 +++++++++++++++++++++++++++ 11 files changed, 253 insertions(+) create mode 100644 xen/arch/arm/tee/Kconfig create mode 100644 xen/arch/arm/tee/Makefile create mode 100644 xen/arch/arm/tee/tee.c create mode 100644 xen/include/asm-arm/tee.h diff --git a/MAINTAINERS b/MAINTAINERS index 77b1e11..ede00c5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -357,6 +357,11 @@ F: config/Stubdom.mk.in F: m4/stubdom.m4 F: stubdom/ +TEE MEDIATORS +M: Volodymyr Babchuk <volodymyr_babchuk@epam.com> +S: Supported +F: xen/arch/arm/tee/* + TOOLSTACK M: Ian Jackson <ian.jackson@eu.citrix.com> M: Wei Liu <wei.liu2@citrix.com> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index d46b98c..e1f112a 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -50,6 +50,14 @@ config HAS_ITS prompt "GICv3 ITS MSI controller support" if EXPERT = "y" depends on HAS_GICV3 +config ARM_TEE + bool "Enable TEE mediators support" + default n + depends on ARM + help + This option enables generic TEE mediators support. It allows guests + to access real TEE via one of TEE mediators implemented in XEN + endmenu menu "ARM errata workaround via the alternative framework" @@ -167,3 +175,5 @@ endmenu source "common/Kconfig" source "drivers/Kconfig" + +source "arch/arm/tee/Kconfig" diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index ede21fd..2710e0e 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64 subdir-y += platforms subdir-$(CONFIG_ARM_64) += efi subdir-$(CONFIG_ACPI) += acpi +subdir-$(CONFIG_ARM_TEE) += tee obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o obj-y += bootfdt.init.o diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 784ae39..3290d39 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -31,6 +31,7 @@ #include <asm/platform.h> #include <asm/procinfo.h> #include <asm/regs.h> +#include <asm/tee.h> #include <asm/vfp.h> #include <asm/vgic.h> #include <asm/vtimer.h> @@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags, if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) goto fail; + /* Notify TEE that new domain was created */ + tee_domain_create(d); + return 0; fail: @@ -684,6 +688,9 @@ fail: void arch_domain_destroy(struct domain *d) { + /* Notify TEE that domain is being destroyed */ + tee_domain_destroy(d); + /* IOMMU page table is shared with P2M, always call * iommu_domain_destroy() before p2m_teardown(). */ diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 92f173b..8a4fcd8 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -47,6 +47,7 @@ #include <asm/platform.h> #include <asm/procinfo.h> #include <asm/setup.h> +#include <asm/tee.h> #include <xsm/xsm.h> #include <asm/acpi.h> @@ -846,6 +847,9 @@ void __init start_xen(unsigned long boot_phys_offset, */ apply_alternatives_all(); + /* Initialize TEE mediator */ + tee_init(); + /* Create initial domain 0. */ /* The vGIC for DOM0 is exactly emulating the hardware GIC */ config.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig new file mode 100644 index 0000000..e69de29 diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile new file mode 100644 index 0000000..c54d479 --- /dev/null +++ b/xen/arch/arm/tee/Makefile @@ -0,0 +1 @@ +obj-y += tee.o diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c new file mode 100644 index 0000000..7f7a846 --- /dev/null +++ b/xen/arch/arm/tee/tee.c @@ -0,0 +1,134 @@ +/* + * xen/arch/arm/tee/tee.c + * + * Generic part of TEE mediator subsystem + * + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> + * Copyright (c) 2017 EPAM Systems. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <xen/types.h> +#include <asm/smccc.h> +#include <asm/tee.h> + +/* + * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner + * for generic TEE queries is 63. + */ +#define TRUSTED_OS_GENERIC_API_OWNER 63 + +#define ARM_SMCCC_FUNC_GET_TEE_UID \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ + ARM_SMCCC_CONV_32, \ + TRUSTED_OS_GENERIC_API_OWNER, \ + ARM_SMCCC_FUNC_CALL_UID) + +extern const struct tee_mediator_desc _steemediator[], _eteemediator[]; +static const struct tee_mediator_ops *mediator_ops; + +/* Helper function to read UID returned by SMC */ +static void parse_uid(const register_t regs[4], xen_uuid_t *uid) +{ + uint8_t *bytes = uid->a; + int n; + + /* + * UID is returned in registers r0..r3, four bytes per register, + * first byte is stored in low-order bits of a register. + * (ARM DEN 0028B page 14) + */ + for (n = 0; n < 16; n++) + bytes[n] = (uint8_t)(regs[n/4] >> ((n & 3) * 8)); + +} + +void tee_init(void) +{ + const struct tee_mediator_desc *desc; + register_t resp[4]; + xen_uuid_t tee_uid; + int ret; + + /* Read UUID to determine which TEE is running */ + call_smccc_smc(ARM_SMCCC_FUNC_GET_TEE_UID, 0, 0, 0, 0, 0, 0, 0, resp); + if ( resp[0] == 0xFFFFFFFF ) { + printk("No TEE found\n"); + return; + } + + parse_uid(resp, &tee_uid); + + printk("TEE UID: %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n", + tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ], + tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ], + tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11], + tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]); + + for ( desc = _steemediator; desc != _eteemediator; desc++ ) + if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 ) + { + printk("Using TEE mediator for %sp\n", desc->name); + mediator_ops = desc->ops; + break; + } + + if ( !mediator_ops ) + return; + + ret = mediator_ops->init(); + if ( ret ) + { + printk("TEE mediator failed to initialize :%d\n", ret); + mediator_ops = NULL; + } +} + +bool tee_handle_smc(struct cpu_user_regs *regs) +{ + if ( !mediator_ops ) + return false; + + return mediator_ops->handle_smc(regs); +} + +void tee_domain_create(struct domain *d) +{ + if ( !mediator_ops ) + return; + + return mediator_ops->domain_create(d); +} + +void tee_domain_destroy(struct domain *d) +{ + if ( !mediator_ops ) + return; + + return mediator_ops->domain_destroy(d); +} + +void tee_remove(void) +{ + if ( !mediator_ops ) + return; + + return mediator_ops->remove(); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c index 7bd6008..186e34b 100644 --- a/xen/arch/arm/vsmc.c +++ b/xen/arch/arm/vsmc.c @@ -22,6 +22,7 @@ #include <asm/psci.h> #include <asm/regs.h> #include <asm/smccc.h> +#include <asm/tee.h> #include <asm/traps.h> /* Number of functions currently supported by Hypervisor Service. */ @@ -288,6 +289,10 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs) case ARM_SMCCC_OWNER_STANDARD: handled = handle_sssc(regs); break; + case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_END: + case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END: + handled = tee_handle_smc(regs); + break; } } diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index c9b9546..b78b7f1 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -126,6 +126,13 @@ SECTIONS _aedevice = .; } :text + . = ALIGN(8); + .teemediator.info : { + _steemediator = .; + *(.teemediator.info) + _eteemediator = .; + } :text + . = ALIGN(PAGE_SIZE); /* Init code and data */ __init_begin = .; .init.text : { diff --git a/xen/include/asm-arm/tee.h b/xen/include/asm-arm/tee.h new file mode 100644 index 0000000..7f500ac --- /dev/null +++ b/xen/include/asm-arm/tee.h @@ -0,0 +1,79 @@ +/* + * xen/include/asm-arm/tee.h + * + * Generic part of TEE mediator subsystem + * + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> + * Copyright (c) 2017 EPAM Systems. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ARCH_ARM_TEE_TEE_H__ +#define __ARCH_ARM_TEE_TEE_H__ + +#include <xen/lib.h> +#include <xen/types.h> +#include <asm/regs.h> + +#ifdef CONFIG_ARM_TEE + +struct tee_mediator_ops { + int (*init)(void); + void (*domain_create)(struct domain *d); + void (*domain_destroy)(struct domain *d); + bool (*handle_smc)(struct cpu_user_regs *regs); + void (*remove)(void); +}; + +struct tee_mediator_desc { + const char *name; + const xen_uuid_t uid; + const struct tee_mediator_ops *ops; +}; + +void tee_init(void); +bool tee_handle_smc(struct cpu_user_regs *regs); +void tee_domain_create(struct domain *d); +void tee_domain_destroy(struct domain *d); +void tee_remove(void); + +#define REGISTER_TEE_MEDIATOR(_name, _namestr, _uid, _ops) \ +static const struct tee_mediator_desc __tee_desc_##_name __used \ +__section(".teemediator.info") = { \ + .name = _namestr, \ + .uid = _uid, \ + .ops = _ops \ +} + +#else + +static inline void tee_init(void) {} +static inline bool tee_handle_smc(struct cpu_user_regs *regs) +{ + return false; +} +static inline void tee_domain_create(struct domain *d) {} +static inline tee_domain_destroy(struct domain *d) {} +static inline tee_remove(void) {} + +#endif /* CONFIG_ARM_TEE */ + +#endif /* __ARCH_ARM_TEE_TEE_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.7.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [RFC 2/4] arm: add generic TEE mediator framework 2017-10-11 19:01 ` [RFC 2/4] arm: add generic TEE mediator framework Volodymyr Babchuk @ 2017-10-16 13:00 ` Julien Grall 2017-10-17 16:22 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-16 13:00 UTC (permalink / raw) To: Volodymyr Babchuk, Stefano Stabellini, Julien Grall, xen-devel Hi Volodymyr, On 11/10/17 20:01, Volodymyr Babchuk wrote: > This patch adds basic framework for TEE mediators. Guests can't talk > to TEE directly, we need some entity that will intercept request > and decide what to do with them. "TEE mediaor" is a such entity. s/mediaor/mediator/ > > This is how it works: user can build XEN with multiple TEE mediators > (see the next patches, where OP-TEE mediator is introduced). > TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in the > same way, as device drivers use DT_DEVICE_START()/DT_DEVICE_END() > macros. > In runtime, during initialization, XEN issues standard SMC to read > TEE UID. Using this UID it selects and initializes one of built-in > mediators. Then generic vSMC handler will call selected mediator > when it intercept SMC that belongs to TEE OS or TEE application. As you may remember the discussion on the SMCCC support for guests, there are currently no way to know the SMCCC is present on the platform. I don't think you can rely on the platform support SMCC nor fully implementing it. This also bring the question of does every TEE are supporting SMCCC? > > Also, there are hooks for domain construction and destruction, so > TEE mediator can inform TEE about VM lifecycle. > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > MAINTAINERS | 5 ++ > xen/arch/arm/Kconfig | 10 ++++ > xen/arch/arm/Makefile | 1 + > xen/arch/arm/domain.c | 7 +++ > xen/arch/arm/setup.c | 4 ++ > xen/arch/arm/tee/Kconfig | 0 > xen/arch/arm/tee/Makefile | 1 + > xen/arch/arm/tee/tee.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++ > xen/arch/arm/vsmc.c | 5 ++ > xen/arch/arm/xen.lds.S | 7 +++ > xen/include/asm-arm/tee.h | 79 +++++++++++++++++++++++++++ > 11 files changed, 253 insertions(+) > create mode 100644 xen/arch/arm/tee/Kconfig > create mode 100644 xen/arch/arm/tee/Makefile > create mode 100644 xen/arch/arm/tee/tee.c > create mode 100644 xen/include/asm-arm/tee.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 77b1e11..ede00c5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -357,6 +357,11 @@ F: config/Stubdom.mk.in > F: m4/stubdom.m4 > F: stubdom/ > > +TEE MEDIATORS > +M: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > +S: Supported > +F: xen/arch/arm/tee/* > + > TOOLSTACK > M: Ian Jackson <ian.jackson@eu.citrix.com> > M: Wei Liu <wei.liu2@citrix.com> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index d46b98c..e1f112a 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -50,6 +50,14 @@ config HAS_ITS > prompt "GICv3 ITS MSI controller support" if EXPERT = "y" > depends on HAS_GICV3 > > +config ARM_TEE The ARM in the title is a bit pointless. This Kconfig is only used for Arm architecture. > + bool "Enable TEE mediators support" > + default n > + depends on ARM No need for that. > + help > + This option enables generic TEE mediators support. It allows guests > + to access real TEE via one of TEE mediators implemented in XEN Missing full stop. > + > endmenu > > menu "ARM errata workaround via the alternative framework" > @@ -167,3 +175,5 @@ endmenu > source "common/Kconfig" > > source "drivers/Kconfig" > + > +source "arch/arm/tee/Kconfig" > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > index ede21fd..2710e0e 100644 > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64 > subdir-y += platforms > subdir-$(CONFIG_ARM_64) += efi > subdir-$(CONFIG_ACPI) += acpi > +subdir-$(CONFIG_ARM_TEE) += tee > > obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o > obj-y += bootfdt.init.o > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 784ae39..3290d39 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -31,6 +31,7 @@ > #include <asm/platform.h> > #include <asm/procinfo.h> > #include <asm/regs.h> > +#include <asm/tee.h> > #include <asm/vfp.h> > #include <asm/vgic.h> > #include <asm/vtimer.h> > @@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags, > if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) > goto fail; > > + /* Notify TEE that new domain was created */ > + tee_domain_create(d); I am not a big fan to see this in arch_domain_create until we see how this is going to fit with guest. For instance, will TEE be for every guests? What would be the other necessary information to configure it?... > + > return 0; > > fail: > @@ -684,6 +688,9 @@ fail: > > void arch_domain_destroy(struct domain *d) > { > + /* Notify TEE that domain is being destroyed */ > + tee_domain_destroy(d); > + > /* IOMMU page table is shared with P2M, always call > * iommu_domain_destroy() before p2m_teardown(). > */ > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 92f173b..8a4fcd8 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -47,6 +47,7 @@ > #include <asm/platform.h> > #include <asm/procinfo.h> > #include <asm/setup.h> > +#include <asm/tee.h> > #include <xsm/xsm.h> > #include <asm/acpi.h> > > @@ -846,6 +847,9 @@ void __init start_xen(unsigned long boot_phys_offset, > */ > apply_alternatives_all(); > > + /* Initialize TEE mediator */ > + tee_init(); > + > /* Create initial domain 0. */ > /* The vGIC for DOM0 is exactly emulating the hardware GIC */ > config.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig > new file mode 100644 > index 0000000..e69de29 > diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile > new file mode 100644 > index 0000000..c54d479 > --- /dev/null > +++ b/xen/arch/arm/tee/Makefile > @@ -0,0 +1 @@ > +obj-y += tee.o > diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c > new file mode 100644 > index 0000000..7f7a846 > --- /dev/null > +++ b/xen/arch/arm/tee/tee.c > @@ -0,0 +1,134 @@ > +/* > + * xen/arch/arm/tee/tee.c > + * > + * Generic part of TEE mediator subsystem > + * > + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> > + * Copyright (c) 2017 EPAM Systems. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <xen/types.h> > +#include <asm/smccc.h> > +#include <asm/tee.h> > + > +/* > + * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner > + * for generic TEE queries is 63. > + */ > +#define TRUSTED_OS_GENERIC_API_OWNER 63 > + > +#define ARM_SMCCC_FUNC_GET_TEE_UID \ > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ > + ARM_SMCCC_CONV_32, \ > + TRUSTED_OS_GENERIC_API_OWNER, \ > + ARM_SMCCC_FUNC_CALL_UID) This likely needs to be defined in smccc as AFAIU it is part of the SMCCC. > + > +extern const struct tee_mediator_desc _steemediator[], _eteemediator[]; > +static const struct tee_mediator_ops *mediator_ops; > + > +/* Helper function to read UID returned by SMC */ > +static void parse_uid(const register_t regs[4], xen_uuid_t *uid) > +{ > + uint8_t *bytes = uid->a; > + int n; unsigned int please. > + > + /* > + * UID is returned in registers r0..r3, four bytes per register, > + * first byte is stored in low-order bits of a register. > + * (ARM DEN 0028B page 14) > + */ > + for (n = 0; n < 16; n++) for ( n = 0; ... ) > + bytes[n] = (uint8_t)(regs[n/4] >> ((n & 3) * 8)); > + > +} > + > +void tee_init(void) > +{ > + const struct tee_mediator_desc *desc; > + register_t resp[4]; > + xen_uuid_t tee_uid; > + int ret; > + > + /* Read UUID to determine which TEE is running */ You can't assume the platform is supporting SMCCC. See my comment at the beginning of the e-mail. > + call_smccc_smc(ARM_SMCCC_FUNC_GET_TEE_UID, 0, 0, 0, 0, 0, 0, 0, resp); > + if ( resp[0] == 0xFFFFFFFF ) { You likely want to use ARM_SMCCC_ERR_UNKOWN_FUNCTION here. > + printk("No TEE found\n"); > + return; > + } > + > + parse_uid(resp, &tee_uid); > + > + printk("TEE UID: %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n", > + tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ], Please no space before ]. This is making more confusing to read. > + tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ], > + tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11], > + tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]); > + > + for ( desc = _steemediator; desc != _eteemediator; desc++ ) { > + if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 ) > + { > + printk("Using TEE mediator for %sp\n", desc->name); > + mediator_ops = desc->ops; > + break; > + } } > + > + if ( !mediator_ops ) A warning here would be useful. > + return; > + > + ret = mediator_ops->init(); > + if ( ret ) > + { > + printk("TEE mediator failed to initialize :%d\n", ret); > + mediator_ops = NULL; > + } > +} > + > +bool tee_handle_smc(struct cpu_user_regs *regs) > +{ > + if ( !mediator_ops ) > + return false; > + > + return mediator_ops->handle_smc(regs); > +} > + > +void tee_domain_create(struct domain *d) > +{ > + if ( !mediator_ops ) > + return; > + > + return mediator_ops->domain_create(d); return here is not necessary. However, I am slightly surprised that tee_domain_create could never fail. > +} > + > +void tee_domain_destroy(struct domain *d) > +{ > + if ( !mediator_ops ) > + return; > + > + return mediator_ops->domain_destroy(d); Same here. > +} > + > +void tee_remove(void) What is this callback for? I don't see any use within this series. > +{ > + if ( !mediator_ops ) > + return; > + > + return mediator_ops->remove(); > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c > index 7bd6008..186e34b 100644 > --- a/xen/arch/arm/vsmc.c > +++ b/xen/arch/arm/vsmc.c > @@ -22,6 +22,7 @@ > #include <asm/psci.h> > #include <asm/regs.h> > #include <asm/smccc.h> > +#include <asm/tee.h> > #include <asm/traps.h> > > /* Number of functions currently supported by Hypervisor Service. */ > @@ -288,6 +289,10 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs) > case ARM_SMCCC_OWNER_STANDARD: > handled = handle_sssc(regs); > break; > + case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_END: > + case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END: > + handled = tee_handle_smc(regs); > + break; > } > } > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S > index c9b9546..b78b7f1 100644 > --- a/xen/arch/arm/xen.lds.S > +++ b/xen/arch/arm/xen.lds.S > @@ -126,6 +126,13 @@ SECTIONS > _aedevice = .; > } :text > > + . = ALIGN(8); > + .teemediator.info : { > + _steemediator = .; > + *(.teemediator.info) > + _eteemediator = .; > + } :text > + > . = ALIGN(PAGE_SIZE); /* Init code and data */ > __init_begin = .; > .init.text : { > diff --git a/xen/include/asm-arm/tee.h b/xen/include/asm-arm/tee.h > new file mode 100644 > index 0000000..7f500ac > --- /dev/null > +++ b/xen/include/asm-arm/tee.h > @@ -0,0 +1,79 @@ > +/* > + * xen/include/asm-arm/tee.h > + * > + * Generic part of TEE mediator subsystem > + * > + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> > + * Copyright (c) 2017 EPAM Systems. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#ifndef __ARCH_ARM_TEE_TEE_H__ > +#define __ARCH_ARM_TEE_TEE_H__ > + > +#include <xen/lib.h> > +#include <xen/types.h> > +#include <asm/regs.h> > + > +#ifdef CONFIG_ARM_TEE > + > +struct tee_mediator_ops { Please add documentations on all the fields to explain their purposes. > + int (*init)(void); > + void (*domain_create)(struct domain *d); > + void (*domain_destroy)(struct domain *d); > + bool (*handle_smc)(struct cpu_user_regs *regs); > + void (*remove)(void); > +}; > + > +struct tee_mediator_desc { Ditto. > + const char *name; > + const xen_uuid_t uid; > + const struct tee_mediator_ops *ops; > +}; > + > +void tee_init(void); > +bool tee_handle_smc(struct cpu_user_regs *regs); > +void tee_domain_create(struct domain *d); > +void tee_domain_destroy(struct domain *d); > +void tee_remove(void); > + > +#define REGISTER_TEE_MEDIATOR(_name, _namestr, _uid, _ops) \ > +static const struct tee_mediator_desc __tee_desc_##_name __used \ > +__section(".teemediator.info") = { \ > + .name = _namestr, \ > + .uid = _uid, \ > + .ops = _ops \ > +} > + > +#else > + > +static inline void tee_init(void) {} > +static inline bool tee_handle_smc(struct cpu_user_regs *regs) > +{ > + return false; > +} > +static inline void tee_domain_create(struct domain *d) {} > +static inline tee_domain_destroy(struct domain *d) {} > +static inline tee_remove(void) {} > + > +#endif /* CONFIG_ARM_TEE */ > + > +#endif /* __ARCH_ARM_TEE_TEE_H__ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 2/4] arm: add generic TEE mediator framework 2017-10-16 13:00 ` Julien Grall @ 2017-10-17 16:22 ` Volodymyr Babchuk 2017-10-17 16:39 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-17 16:22 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, Stefano Stabellini, xen-devel On Mon, Oct 16, 2017 at 02:00:32PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, [...] > >This is how it works: user can build XEN with multiple TEE mediators > >(see the next patches, where OP-TEE mediator is introduced). > >TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in the > >same way, as device drivers use DT_DEVICE_START()/DT_DEVICE_END() > >macros. > >In runtime, during initialization, XEN issues standard SMC to read > >TEE UID. Using this UID it selects and initializes one of built-in > >mediators. Then generic vSMC handler will call selected mediator > >when it intercept SMC that belongs to TEE OS or TEE application. > > As you may remember the discussion on the SMCCC support for guests, there > are currently no way to know the SMCCC is present on the platform. Ah, yes. Device tree, then. > I don't think you can rely on the platform support SMCC nor fully > implementing it. This also bring the question of does every TEE are > supporting SMCCC? Honestly, I don't know. I suppose that there can be TEEs the are not compatible with SMCCC. Okay, instead of UID comparison in generic framework, I can introduce probe() functions for each mediator. On other hand, DT bindings, can work even better. How about this: TEE mediator registers with DT_DEVICE_START() as any other driver. If, during init() it finds compatible TEE, then TEE mediator registers itself in TEE framework. During registration it provides supported SMC fn ranges. This is for case when TEE is not SMCCC-compatible and uses function numbers outside ARM_SMCCC_OWNER_TRUSTED_OS range. > > > >Also, there are hooks for domain construction and destruction, so > >TEE mediator can inform TEE about VM lifecycle. > > > >Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >--- > > MAINTAINERS | 5 ++ > > xen/arch/arm/Kconfig | 10 ++++ > > xen/arch/arm/Makefile | 1 + > > xen/arch/arm/domain.c | 7 +++ > > xen/arch/arm/setup.c | 4 ++ > > xen/arch/arm/tee/Kconfig | 0 > > xen/arch/arm/tee/Makefile | 1 + > > xen/arch/arm/tee/tee.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++ > > xen/arch/arm/vsmc.c | 5 ++ > > xen/arch/arm/xen.lds.S | 7 +++ > > xen/include/asm-arm/tee.h | 79 +++++++++++++++++++++++++++ > > 11 files changed, 253 insertions(+) > > create mode 100644 xen/arch/arm/tee/Kconfig > > create mode 100644 xen/arch/arm/tee/Makefile > > create mode 100644 xen/arch/arm/tee/tee.c > > create mode 100644 xen/include/asm-arm/tee.h > > > >diff --git a/MAINTAINERS b/MAINTAINERS > >index 77b1e11..ede00c5 100644 > >--- a/MAINTAINERS > >+++ b/MAINTAINERS > >@@ -357,6 +357,11 @@ F: config/Stubdom.mk.in > > F: m4/stubdom.m4 > > F: stubdom/ > >+TEE MEDIATORS > >+M: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >+S: Supported > >+F: xen/arch/arm/tee/* > >+ > > TOOLSTACK > > M: Ian Jackson <ian.jackson@eu.citrix.com> > > M: Wei Liu <wei.liu2@citrix.com> > >diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > >index d46b98c..e1f112a 100644 > >--- a/xen/arch/arm/Kconfig > >+++ b/xen/arch/arm/Kconfig > >@@ -50,6 +50,14 @@ config HAS_ITS > > prompt "GICv3 ITS MSI controller support" if EXPERT = "y" > > depends on HAS_GICV3 > >+config ARM_TEE > > The ARM in the title is a bit pointless. This Kconfig is only used for Arm > architecture. Just plain TEE then? > >+ bool "Enable TEE mediators support" > >+ default n > >+ depends on ARM > > No need for that. Right. > >+ help > >+ This option enables generic TEE mediators support. It allows guests > >+ to access real TEE via one of TEE mediators implemented in XEN > > Missing full stop. > > >+ > > endmenu > > menu "ARM errata workaround via the alternative framework" > >@@ -167,3 +175,5 @@ endmenu > > source "common/Kconfig" > > source "drivers/Kconfig" > >+ > >+source "arch/arm/tee/Kconfig" > >diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > >index ede21fd..2710e0e 100644 > >--- a/xen/arch/arm/Makefile > >+++ b/xen/arch/arm/Makefile > >@@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64 > > subdir-y += platforms > > subdir-$(CONFIG_ARM_64) += efi > > subdir-$(CONFIG_ACPI) += acpi > >+subdir-$(CONFIG_ARM_TEE) += tee > > obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o > > obj-y += bootfdt.init.o > >diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > >index 784ae39..3290d39 100644 > >--- a/xen/arch/arm/domain.c > >+++ b/xen/arch/arm/domain.c > >@@ -31,6 +31,7 @@ > > #include <asm/platform.h> > > #include <asm/procinfo.h> > > #include <asm/regs.h> > >+#include <asm/tee.h> > > #include <asm/vfp.h> > > #include <asm/vgic.h> > > #include <asm/vtimer.h> > >@@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags, > > if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) > > goto fail; > >+ /* Notify TEE that new domain was created */ > >+ tee_domain_create(d); > > I am not a big fan to see this in arch_domain_create until we see how this > is going to fit with guest. For instance, will TEE be for every guests? What > would be the other necessary information to configure it?... I think I'll call XSM in tee_domain_create() to check if this domain allowed to work with TEE. I can't imagine what additional information will be needed. This interface can be extended in the future, though. > >+ > > return 0; > > fail: > >@@ -684,6 +688,9 @@ fail: > > void arch_domain_destroy(struct domain *d) > > { > >+ /* Notify TEE that domain is being destroyed */ > >+ tee_domain_destroy(d); > >+ > > /* IOMMU page table is shared with P2M, always call > > * iommu_domain_destroy() before p2m_teardown(). > > */ > >diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > >index 92f173b..8a4fcd8 100644 > >--- a/xen/arch/arm/setup.c > >+++ b/xen/arch/arm/setup.c > >@@ -47,6 +47,7 @@ > > #include <asm/platform.h> > > #include <asm/procinfo.h> > > #include <asm/setup.h> > >+#include <asm/tee.h> > > #include <xsm/xsm.h> > > #include <asm/acpi.h> > >@@ -846,6 +847,9 @@ void __init start_xen(unsigned long boot_phys_offset, > > */ > > apply_alternatives_all(); > >+ /* Initialize TEE mediator */ > >+ tee_init(); > >+ > > /* Create initial domain 0. */ > > /* The vGIC for DOM0 is exactly emulating the hardware GIC */ > > config.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > >diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig > >new file mode 100644 > >index 0000000..e69de29 > >diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile > >new file mode 100644 > >index 0000000..c54d479 > >--- /dev/null > >+++ b/xen/arch/arm/tee/Makefile > >@@ -0,0 +1 @@ > >+obj-y += tee.o > >diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c > >new file mode 100644 > >index 0000000..7f7a846 > >--- /dev/null > >+++ b/xen/arch/arm/tee/tee.c > >@@ -0,0 +1,134 @@ > >+/* > >+ * xen/arch/arm/tee/tee.c > >+ * > >+ * Generic part of TEE mediator subsystem > >+ * > >+ * Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >+ * Copyright (c) 2017 EPAM Systems. > >+ * > >+ * This program is free software; you can redistribute it and/or modify > >+ * it under the terms of the GNU General Public License version 2 as > >+ * published by the Free Software Foundation. > >+ * > >+ * This program is distributed in the hope that it will be useful, > >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of > >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >+ * GNU General Public License for more details. > >+ */ > >+ > >+#include <xen/types.h> > >+#include <asm/smccc.h> > >+#include <asm/tee.h> > >+ > >+/* > >+ * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner > >+ * for generic TEE queries is 63. > >+ */ > >+#define TRUSTED_OS_GENERIC_API_OWNER 63 > >+ > >+#define ARM_SMCCC_FUNC_GET_TEE_UID \ > >+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ > >+ ARM_SMCCC_CONV_32, \ > >+ TRUSTED_OS_GENERIC_API_OWNER, \ > >+ ARM_SMCCC_FUNC_CALL_UID) > > This likely needs to be defined in smccc as AFAIU it is part of the SMCCC. It only used there. I'm not sure if I should define it globally. > >+ > >+extern const struct tee_mediator_desc _steemediator[], _eteemediator[]; > >+static const struct tee_mediator_ops *mediator_ops; > >+ > >+/* Helper function to read UID returned by SMC */ > >+static void parse_uid(const register_t regs[4], xen_uuid_t *uid) > >+{ > >+ uint8_t *bytes = uid->a; > >+ int n; > > unsigned int please. > > >+ > >+ /* > >+ * UID is returned in registers r0..r3, four bytes per register, > >+ * first byte is stored in low-order bits of a register. > >+ * (ARM DEN 0028B page 14) > >+ */ > >+ for (n = 0; n < 16; n++) > > for ( n = 0; ... ) Yeah, sorry. It is hard to hold multiple coding styles in mind at the same time. I hope, Yurii will finish his coding style validator soon :) > >+ bytes[n] = (uint8_t)(regs[n/4] >> ((n & 3) * 8)); > >+ > >+} > >+ > >+void tee_init(void) > >+{ > >+ const struct tee_mediator_desc *desc; > >+ register_t resp[4]; > >+ xen_uuid_t tee_uid; > >+ int ret; > >+ > >+ /* Read UUID to determine which TEE is running */ > > You can't assume the platform is supporting SMCCC. See my comment at the > beginning of the e-mail. Yeah, looks like this part will be completely reworked. > >+ call_smccc_smc(ARM_SMCCC_FUNC_GET_TEE_UID, 0, 0, 0, 0, 0, 0, 0, resp); > >+ if ( resp[0] == 0xFFFFFFFF ) { > > You likely want to use ARM_SMCCC_ERR_UNKOWN_FUNCTION here. > > >+ printk("No TEE found\n"); > >+ return; > >+ } > >+ > >+ parse_uid(resp, &tee_uid); > >+ > >+ printk("TEE UID: %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n", > >+ tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ], > > Please no space before ]. This is making more confusing to read. I put it for neat formatting. Probably, I can put double space after commas. Will be okay? > >+ tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ], > >+ tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11], > >+ tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]); > >+ > >+ for ( desc = _steemediator; desc != _eteemediator; desc++ ) > > { > > >+ if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 ) > >+ { > >+ printk("Using TEE mediator for %sp\n", desc->name); > >+ mediator_ops = desc->ops; > >+ break; > >+ } > > } > > >+ > >+ if ( !mediator_ops ) > > A warning here would be useful. Why? Platform is not obligued to have any TEE. > >+ return; > >+ > >+ ret = mediator_ops->init(); > >+ if ( ret ) > >+ { > >+ printk("TEE mediator failed to initialize :%d\n", ret); > >+ mediator_ops = NULL; > >+ } > >+} > >+ > >+bool tee_handle_smc(struct cpu_user_regs *regs) > >+{ > >+ if ( !mediator_ops ) > >+ return false; > >+ > >+ return mediator_ops->handle_smc(regs); > >+} > >+ > >+void tee_domain_create(struct domain *d) > >+{ > >+ if ( !mediator_ops ) > >+ return; > >+ > >+ return mediator_ops->domain_create(d); > > return here is not necessary. However, I am slightly surprised that > tee_domain_create could never fail. Good question. Do you want to allow TEE to prevent domain creation? > >+} > >+ > >+void tee_domain_destroy(struct domain *d) > >+{ > >+ if ( !mediator_ops ) > >+ return; > >+ > >+ return mediator_ops->domain_destroy(d); > > Same here. > > >+} > >+ > >+void tee_remove(void) > > What is this callback for? I don't see any use within this series. Sorry, missed to call it. [...] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 2/4] arm: add generic TEE mediator framework 2017-10-17 16:22 ` Volodymyr Babchuk @ 2017-10-17 16:39 ` Julien Grall 2017-10-17 17:22 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-17 16:39 UTC (permalink / raw) To: Volodymyr Babchuk; +Cc: Julien Grall, Stefano Stabellini, xen-devel On 17/10/17 17:22, Volodymyr Babchuk wrote: > On Mon, Oct 16, 2017 at 02:00:32PM +0100, Julien Grall wrote: >>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >>> index d46b98c..e1f112a 100644 >>> --- a/xen/arch/arm/Kconfig >>> +++ b/xen/arch/arm/Kconfig >>> @@ -50,6 +50,14 @@ config HAS_ITS >>> prompt "GICv3 ITS MSI controller support" if EXPERT = "y" >>> depends on HAS_GICV3 >>> +config ARM_TEE >> >> The ARM in the title is a bit pointless. This Kconfig is only used for Arm >> architecture. > Just plain TEE then? Yes please. > >>> + bool "Enable TEE mediators support" >>> + default n >>> + depends on ARM >> >> No need for that. > Right. > >>> + help >>> + This option enables generic TEE mediators support. It allows guests >>> + to access real TEE via one of TEE mediators implemented in XEN >> >> Missing full stop. >> >>> + >>> endmenu >>> menu "ARM errata workaround via the alternative framework" >>> @@ -167,3 +175,5 @@ endmenu >>> source "common/Kconfig" >>> source "drivers/Kconfig" >>> + >>> +source "arch/arm/tee/Kconfig" >>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile >>> index ede21fd..2710e0e 100644 >>> --- a/xen/arch/arm/Makefile >>> +++ b/xen/arch/arm/Makefile >>> @@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64 >>> subdir-y += platforms >>> subdir-$(CONFIG_ARM_64) += efi >>> subdir-$(CONFIG_ACPI) += acpi >>> +subdir-$(CONFIG_ARM_TEE) += tee >>> obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o >>> obj-y += bootfdt.init.o >>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >>> index 784ae39..3290d39 100644 >>> --- a/xen/arch/arm/domain.c >>> +++ b/xen/arch/arm/domain.c >>> @@ -31,6 +31,7 @@ >>> #include <asm/platform.h> >>> #include <asm/procinfo.h> >>> #include <asm/regs.h> >>> +#include <asm/tee.h> >>> #include <asm/vfp.h> >>> #include <asm/vgic.h> >>> #include <asm/vtimer.h> >>> @@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags, >>> if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) >>> goto fail; >>> + /* Notify TEE that new domain was created */ >>> + tee_domain_create(d); >> >> I am not a big fan to see this in arch_domain_create until we see how this >> is going to fit with guest. For instance, will TEE be for every guests? What >> would be the other necessary information to configure it?... > I think I'll call XSM in tee_domain_create() to check if this domain allowed > to work with TEE. I can't imagine what additional information will be needed. > This interface can be extended in the future, though. You will never need to inform TEE that a new client (aka domain) is been created, nor allocated memory for the TEE at domain creation in Xen? [...] >>> diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c >>> new file mode 100644 >>> index 0000000..7f7a846 >>> --- /dev/null >>> +++ b/xen/arch/arm/tee/tee.c >>> @@ -0,0 +1,134 @@ >>> +/* >>> + * xen/arch/arm/tee/tee.c >>> + * >>> + * Generic part of TEE mediator subsystem >>> + * >>> + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>> + * Copyright (c) 2017 EPAM Systems. >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License version 2 as >>> + * published by the Free Software Foundation. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + */ >>> + >>> +#include <xen/types.h> >>> +#include <asm/smccc.h> >>> +#include <asm/tee.h> >>> + >>> +/* >>> + * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner >>> + * for generic TEE queries is 63. >>> + */ >>> +#define TRUSTED_OS_GENERIC_API_OWNER 63 >>> + >>> +#define ARM_SMCCC_FUNC_GET_TEE_UID \ >>> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ >>> + ARM_SMCCC_CONV_32, \ >>> + TRUSTED_OS_GENERIC_API_OWNER, \ >>> + ARM_SMCCC_FUNC_CALL_UID) >> >> This likely needs to be defined in smccc as AFAIU it is part of the SMCCC. > It only used there. I'm not sure if I should define it globally. Maybe ARM_SMCCC_FUNC_GET_TEE_UID, but definitely TRUSTED_OS_GENERIC_API_OWNER should stick with the rest of the subsystem definition in smccc.h. [...] >>> + printk("No TEE found\n"); >>> + return; >>> + } >>> + >>> + parse_uid(resp, &tee_uid); >>> + >>> + printk("TEE UID: %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n", >>> + tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ], >> >> Please no space before ]. This is making more confusing to read. > I put it for neat formatting. Probably, I can put double space after commas. > Will be okay? That is that really important to have them? I mean, ok it is not going to be neat but the format string is already ugly and it would not be too difficult to read the arguments. > >>> + tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ], >>> + tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11], >>> + tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]); >>> + >>> + for ( desc = _steemediator; desc != _eteemediator; desc++ ) >> >> { >> >>> + if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 ) >>> + { >>> + printk("Using TEE mediator for %sp\n", desc->name); >>> + mediator_ops = desc->ops; >>> + break; >>> + } >> >> } >> >>> + >>> + if ( !mediator_ops ) >> >> A warning here would be useful. > Why? Platform is not obligued to have any TEE. What do you mean? You can only be here because the platform has TEE but Xen does not have any mediator. You actually print "no TEE found" a bit above. So why not printing for when Xen is unable to use it? > >>> + return; >>> + >>> + ret = mediator_ops->init(); >>> + if ( ret ) >>> + { >>> + printk("TEE mediator failed to initialize :%d\n", ret); >>> + mediator_ops = NULL; >>> + } >>> +} >>> + >>> +bool tee_handle_smc(struct cpu_user_regs *regs) >>> +{ >>> + if ( !mediator_ops ) >>> + return false; >>> + >>> + return mediator_ops->handle_smc(regs); >>> +} >>> + >>> +void tee_domain_create(struct domain *d) >>> +{ >>> + if ( !mediator_ops ) >>> + return; >>> + >>> + return mediator_ops->domain_create(d); >> >> return here is not necessary. However, I am slightly surprised that >> tee_domain_create could never fail. > Good question. Do you want to allow TEE to prevent domain creation? See my answer a bit above on the call. > >>> +} >>> + >>> +void tee_domain_destroy(struct domain *d) >>> +{ >>> + if ( !mediator_ops ) >>> + return; >>> + >>> + return mediator_ops->domain_destroy(d); >> >> Same here. >> >>> +} >>> + >>> +void tee_remove(void) >> >> What is this callback for? I don't see any use within this series. > Sorry, missed to call it. > > [...] > Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 2/4] arm: add generic TEE mediator framework 2017-10-17 16:39 ` Julien Grall @ 2017-10-17 17:22 ` Volodymyr Babchuk 2017-10-17 17:35 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-17 17:22 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, Stefano Stabellini, xen-devel Hi Julien, On Tue, Oct 17, 2017 at 05:39:29PM +0100, Julien Grall wrote: Excuse me, looks like you skipped my thoughts about how to detect TEE if we are not sure, that we are running on SMCCC-capable platform. How do you think, is it appropriate to rely on DT? [...] > >>>@@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags, > >>> if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) > >>> goto fail; > >>>+ /* Notify TEE that new domain was created */ > >>>+ tee_domain_create(d); > >> > >>I am not a big fan to see this in arch_domain_create until we see how this > >>is going to fit with guest. For instance, will TEE be for every guests? What > >>would be the other necessary information to configure it?... > >I think I'll call XSM in tee_domain_create() to check if this domain allowed > >to work with TEE. I can't imagine what additional information will be needed. > >This interface can be extended in the future, though. > > You will never need to inform TEE that a new client (aka domain) is been > created, nor allocated memory for the TEE at domain creation in Xen? Yes. You are right. But then there are another question: what to do if tee_domain_create() failed? Prevent domain creation? Or create domain anyways, but forbid it to call TEE? > [...] > > >>>diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c > >>>new file mode 100644 > >>>index 0000000..7f7a846 > >>>--- /dev/null > >>>+++ b/xen/arch/arm/tee/tee.c > >>>@@ -0,0 +1,134 @@ > >>>+/* > >>>+ * xen/arch/arm/tee/tee.c > >>>+ * > >>>+ * Generic part of TEE mediator subsystem > >>>+ * > >>>+ * Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >>>+ * Copyright (c) 2017 EPAM Systems. > >>>+ * > >>>+ * This program is free software; you can redistribute it and/or modify > >>>+ * it under the terms of the GNU General Public License version 2 as > >>>+ * published by the Free Software Foundation. > >>>+ * > >>>+ * This program is distributed in the hope that it will be useful, > >>>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of > >>>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >>>+ * GNU General Public License for more details. > >>>+ */ > >>>+ > >>>+#include <xen/types.h> > >>>+#include <asm/smccc.h> > >>>+#include <asm/tee.h> > >>>+ > >>>+/* > >>>+ * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner > >>>+ * for generic TEE queries is 63. > >>>+ */ > >>>+#define TRUSTED_OS_GENERIC_API_OWNER 63 > >>>+ > >>>+#define ARM_SMCCC_FUNC_GET_TEE_UID \ > >>>+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ > >>>+ ARM_SMCCC_CONV_32, \ > >>>+ TRUSTED_OS_GENERIC_API_OWNER, \ > >>>+ ARM_SMCCC_FUNC_CALL_UID) > >> > >>This likely needs to be defined in smccc as AFAIU it is part of the SMCCC. > >It only used there. I'm not sure if I should define it globally. > > Maybe ARM_SMCCC_FUNC_GET_TEE_UID, but definitely > TRUSTED_OS_GENERIC_API_OWNER should stick with the rest of the subsystem > definition in smccc.h. Yes, will do in this way. > [...] > > >>>+ printk("No TEE found\n"); > >>>+ return; > >>>+ } > >>>+ > >>>+ parse_uid(resp, &tee_uid); > >>>+ > >>>+ printk("TEE UID: %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n", > >>>+ tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ], > >> > >>Please no space before ]. This is making more confusing to read. > >I put it for neat formatting. Probably, I can put double space after commas. > >Will be okay? > > That is that really important to have them? I mean, ok it is not going to be > neat but the format string is already ugly and it would not be too difficult > to read the arguments. Dunno. As for me, it eases parsing. For example, it is easy to see that all indexes are correct. But if this is inappropriate, I can remove all extra spaces. > > > > >>>+ tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ], > >>>+ tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11], > >>>+ tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]); > >>>+ > >>>+ for ( desc = _steemediator; desc != _eteemediator; desc++ ) > >> > >>{ > >> > >>>+ if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 ) > >>>+ { > >>>+ printk("Using TEE mediator for %sp\n", desc->name); > >>>+ mediator_ops = desc->ops; > >>>+ break; > >>>+ } > >> > >>} > >> > >>>+ > >>>+ if ( !mediator_ops ) > >> > >>A warning here would be useful. > >Why? Platform is not obligued to have any TEE. > > What do you mean? You can only be here because the platform has TEE but Xen > does not have any mediator. You actually print "no TEE found" a bit above. > So why not printing for when Xen is unable to use it? Ah, yes. This makes sense. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 2/4] arm: add generic TEE mediator framework 2017-10-17 17:22 ` Volodymyr Babchuk @ 2017-10-17 17:35 ` Julien Grall 0 siblings, 0 replies; 44+ messages in thread From: Julien Grall @ 2017-10-17 17:35 UTC (permalink / raw) To: Volodymyr Babchuk; +Cc: Julien Grall, Stefano Stabellini, xen-devel On 17/10/17 18:22, Volodymyr Babchuk wrote: > Hi Julien, > > On Tue, Oct 17, 2017 at 05:39:29PM +0100, Julien Grall wrote: > > Excuse me, looks like you skipped my thoughts about how to detect > TEE if we are not sure, that we are running on SMCCC-capable platform. > > How do you think, is it appropriate to rely on DT? I didn't have any opinion as long as it covers most of the TEE and does not make any assumption on the platform other than written in the ARM ARM. I have no idea how Linux is doing the detection, it might be worth for you to have a look there. > > [...] >>>>> @@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags, >>>>> if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) >>>>> goto fail; >>>>> + /* Notify TEE that new domain was created */ >>>>> + tee_domain_create(d); >>>> >>>> I am not a big fan to see this in arch_domain_create until we see how this >>>> is going to fit with guest. For instance, will TEE be for every guests? What >>>> would be the other necessary information to configure it?... >>> I think I'll call XSM in tee_domain_create() to check if this domain allowed >>> to work with TEE. I can't imagine what additional information will be needed. >>> This interface can be extended in the future, though. >> >> You will never need to inform TEE that a new client (aka domain) is been >> created, nor allocated memory for the TEE at domain creation in Xen? > Yes. You are right. But then there are another question: what to do > if tee_domain_create() failed? Prevent domain creation? Or create > domain anyways, but forbid it to call TEE? I would expect TEE to not be enabled by default for guests. This would be user configurable. So if it requests TEE and it is not possible to instantiate one, then the domain creation should failed. > >> [...] >> >>>>> diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c >>>>> new file mode 100644 >>>>> index 0000000..7f7a846 >>>>> --- /dev/null >>>>> +++ b/xen/arch/arm/tee/tee.c >>>>> @@ -0,0 +1,134 @@ >>>>> +/* >>>>> + * xen/arch/arm/tee/tee.c >>>>> + * >>>>> + * Generic part of TEE mediator subsystem >>>>> + * >>>>> + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>>>> + * Copyright (c) 2017 EPAM Systems. >>>>> + * >>>>> + * This program is free software; you can redistribute it and/or modify >>>>> + * it under the terms of the GNU General Public License version 2 as >>>>> + * published by the Free Software Foundation. >>>>> + * >>>>> + * This program is distributed in the hope that it will be useful, >>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>>> + * GNU General Public License for more details. >>>>> + */ >>>>> + >>>>> +#include <xen/types.h> >>>>> +#include <asm/smccc.h> >>>>> +#include <asm/tee.h> >>>>> + >>>>> +/* >>>>> + * According to ARM SMCCC (ARM DEN 0028B, page 17), service owner >>>>> + * for generic TEE queries is 63. >>>>> + */ >>>>> +#define TRUSTED_OS_GENERIC_API_OWNER 63 >>>>> + >>>>> +#define ARM_SMCCC_FUNC_GET_TEE_UID \ >>>>> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ >>>>> + ARM_SMCCC_CONV_32, \ >>>>> + TRUSTED_OS_GENERIC_API_OWNER, \ >>>>> + ARM_SMCCC_FUNC_CALL_UID) >>>> >>>> This likely needs to be defined in smccc as AFAIU it is part of the SMCCC. >>> It only used there. I'm not sure if I should define it globally. >> >> Maybe ARM_SMCCC_FUNC_GET_TEE_UID, but definitely >> TRUSTED_OS_GENERIC_API_OWNER should stick with the rest of the subsystem >> definition in smccc.h. > Yes, will do in this way. > >> [...] >> >>>>> + printk("No TEE found\n"); >>>>> + return; >>>>> + } >>>>> + >>>>> + parse_uid(resp, &tee_uid); >>>>> + >>>>> + printk("TEE UID: %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n", >>>>> + tee_uid.a[0 ], tee_uid.a[1 ], tee_uid.a[2 ], tee_uid.a[3 ], >>>> >>>> Please no space before ]. This is making more confusing to read. >>> I put it for neat formatting. Probably, I can put double space after commas. >>> Will be okay? >> >> That is that really important to have them? I mean, ok it is not going to be >> neat but the format string is already ugly and it would not be too difficult >> to read the arguments. > Dunno. As for me, it eases parsing. For example, it is easy to see that > all indexes are correct. But if this is inappropriate, I can remove all > extra spaces. Well, if you are going to do a different probe than via SMCCC, then this discussion is not necessary as the printk would likely disappear. >> >>> >>>>> + tee_uid.a[4 ], tee_uid.a[5 ], tee_uid.a[6 ], tee_uid.a[7 ], >>>>> + tee_uid.a[8 ], tee_uid.a[9 ], tee_uid.a[10], tee_uid.a[11], >>>>> + tee_uid.a[12], tee_uid.a[13], tee_uid.a[14], tee_uid.a[15]); >>>>> + >>>>> + for ( desc = _steemediator; desc != _eteemediator; desc++ ) >>>> >>>> { >>>> >>>>> + if ( memcmp(&desc->uid, &tee_uid, sizeof(xen_uuid_t)) == 0 ) >>>>> + { >>>>> + printk("Using TEE mediator for %sp\n", desc->name); >>>>> + mediator_ops = desc->ops; >>>>> + break; >>>>> + } >>>> >>>> } >>>> >>>>> + >>>>> + if ( !mediator_ops ) >>>> >>>> A warning here would be useful. >>> Why? Platform is not obligued to have any TEE. >> >> What do you mean? You can only be here because the platform has TEE but Xen >> does not have any mediator. You actually print "no TEE found" a bit above. >> So why not printing for when Xen is unable to use it? > Ah, yes. This makes sense. > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* [RFC 3/4] arm: tee: add OP-TEE header files 2017-10-11 19:01 [RFC 0/4] TEE mediator framework + OP-TEE mediator Volodymyr Babchuk 2017-10-11 19:01 ` [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC Volodymyr Babchuk 2017-10-11 19:01 ` [RFC 2/4] arm: add generic TEE mediator framework Volodymyr Babchuk @ 2017-10-11 19:01 ` Volodymyr Babchuk 2017-10-16 14:04 ` Julien Grall 2017-10-11 19:01 ` [RFC 4/4] arm: tee: add basic OP-TEE mediator Volodymyr Babchuk 2017-10-16 12:00 ` [RFC 0/4] TEE mediator framework + " Julien Grall 4 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-11 19:01 UTC (permalink / raw) To: Stefano Stabellini, Julien Grall, xen-devel; +Cc: Volodymyr Babchuk This header files describe protocol between OP-TEE and OP-TEE client driver in Linux. They are needed for upcomient OP-TEE mediator, which is added in the next patch. Reason to add those headers in separate patch is to ease up review. Those files were taken from linux tree (drivers/tee/optee/) and mangled a bit to compile with XEN. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> --- xen/arch/arm/tee/optee_msg.h | 444 +++++++++++++++++++++++++++++++++++++++++ xen/arch/arm/tee/optee_smc.h | 457 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 901 insertions(+) create mode 100644 xen/arch/arm/tee/optee_msg.h create mode 100644 xen/arch/arm/tee/optee_smc.h diff --git a/xen/arch/arm/tee/optee_msg.h b/xen/arch/arm/tee/optee_msg.h new file mode 100644 index 0000000..10747b2 --- /dev/null +++ b/xen/arch/arm/tee/optee_msg.h @@ -0,0 +1,444 @@ +/* + * Copyright (c) 2015-2016, Linaro Limited + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + * this list of conditions and the following disclaimer in the documentation + * and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ +#ifndef _OPTEE_MSG_H +#define _OPTEE_MSG_H + +#include <xen/bitops.h> +#include <xen/types.h> + +/* + * This file defines the OP-TEE message protocol used to communicate + * with an instance of OP-TEE running in secure world. + * + * This file is divided into three sections. + * 1. Formatting of messages. + * 2. Requests from normal world + * 3. Requests from secure world, Remote Procedure Call (RPC), handled by + * tee-supplicant. + */ + +/***************************************************************************** + * Part 1 - formatting of messages + *****************************************************************************/ + +#define OPTEE_MSG_ATTR_TYPE_NONE 0x0 +#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT 0x1 +#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT 0x2 +#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT 0x3 +#define OPTEE_MSG_ATTR_TYPE_RMEM_INPUT 0x5 +#define OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT 0x6 +#define OPTEE_MSG_ATTR_TYPE_RMEM_INOUT 0x7 +#define OPTEE_MSG_ATTR_TYPE_TMEM_INPUT 0x9 +#define OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT 0xa +#define OPTEE_MSG_ATTR_TYPE_TMEM_INOUT 0xb + +#define OPTEE_MSG_ATTR_TYPE_MASK GENMASK(7, 0) + +/* + * Meta parameter to be absorbed by the Secure OS and not passed + * to the Trusted Application. + * + * Currently only used with OPTEE_MSG_CMD_OPEN_SESSION. + */ +#define OPTEE_MSG_ATTR_META BIT(8) + +/* + * Pointer to a list of pages used to register user-defined SHM buffer. + * Used with OPTEE_MSG_ATTR_TYPE_TMEM_*. + * buf_ptr should point to the beginning of the buffer. Buffer will contain + * list of page addresses. OP-TEE core can reconstruct contiguous buffer from + * that page addresses list. Page addresses are stored as 64 bit values. + * Last entry on a page should point to the next page of buffer. + * Every entry in buffer should point to a 4k page beginning (12 least + * significant bits must be equal to zero). + * + * 12 least significant bints of optee_msg_param.u.tmem.buf_ptr should hold page + * offset of the user buffer. + * + * So, entries should be placed like members of this structure: + * + * struct page_data { + * uint64_t pages_array[OPTEE_MSG_NONCONTIG_PAGE_SIZE/sizeof(uint64_t) - 1]; + * uint64_t next_page_data; + * }; + * + * Structure is designed to exactly fit into the page size + * OPTEE_MSG_NONCONTIG_PAGE_SIZE which is a standard 4KB page. + * + * The size of 4KB is chosen because this is the smallest page size for ARM + * architectures. If REE uses larger pages, it should divide them to 4KB ones. + */ +#define OPTEE_MSG_ATTR_NONCONTIG BIT(9) + +/* + * Memory attributes for caching passed with temp memrefs. The actual value + * used is defined outside the message protocol with the exception of + * OPTEE_MSG_ATTR_CACHE_PREDEFINED which means the attributes already + * defined for the memory range should be used. If optee_smc.h is used as + * bearer of this protocol OPTEE_SMC_SHM_* is used for values. + */ +#define OPTEE_MSG_ATTR_CACHE_SHIFT 16 +#define OPTEE_MSG_ATTR_CACHE_MASK GENMASK(2, 0) +#define OPTEE_MSG_ATTR_CACHE_PREDEFINED 0 + +/* + * Same values as TEE_LOGIN_* from TEE Internal API + */ +#define OPTEE_MSG_LOGIN_PUBLIC 0x00000000 +#define OPTEE_MSG_LOGIN_USER 0x00000001 +#define OPTEE_MSG_LOGIN_GROUP 0x00000002 +#define OPTEE_MSG_LOGIN_APPLICATION 0x00000004 +#define OPTEE_MSG_LOGIN_APPLICATION_USER 0x00000005 +#define OPTEE_MSG_LOGIN_APPLICATION_GROUP 0x00000006 + +/* + * Page size used in non-contiguous buffer entries + */ +#define OPTEE_MSG_NONCONTIG_PAGE_SIZE 4096 + +/** + * struct optee_msg_param_tmem - temporary memory reference parameter + * @buf_ptr: Address of the buffer + * @size: Size of the buffer + * @shm_ref: Temporary shared memory reference, pointer to a struct tee_shm + * + * Secure and normal world communicates pointers as physical address + * instead of the virtual address. This is because secure and normal world + * have completely independent memory mapping. Normal world can even have a + * hypervisor which need to translate the guest physical address (AKA IPA + * in ARM documentation) to a real physical address before passing the + * structure to secure world. + */ +struct optee_msg_param_tmem { + u64 buf_ptr; + u64 size; + u64 shm_ref; +}; + +/** + * struct optee_msg_param_rmem - registered memory reference parameter + * @offs: Offset into shared memory reference + * @size: Size of the buffer + * @shm_ref: Shared memory reference, pointer to a struct tee_shm + */ +struct optee_msg_param_rmem { + u64 offs; + u64 size; + u64 shm_ref; +}; + +/** + * struct optee_msg_param_value - opaque value parameter + * + * Value parameters are passed unchecked between normal and secure world. + */ +struct optee_msg_param_value { + u64 a; + u64 b; + u64 c; +}; + +/** + * struct optee_msg_param - parameter used together with struct optee_msg_arg + * @attr: attributes + * @tmem: parameter by temporary memory reference + * @rmem: parameter by registered memory reference + * @value: parameter by opaque value + * + * @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in + * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value, + * OPTEE_MSG_ATTR_TYPE_TMEM_* indicates @tmem and + * OPTEE_MSG_ATTR_TYPE_RMEM_* indicates @rmem, + * OPTEE_MSG_ATTR_TYPE_NONE indicates that none of the members are used. + */ +struct optee_msg_param { + u64 attr; + union { + struct optee_msg_param_tmem tmem; + struct optee_msg_param_rmem rmem; + struct optee_msg_param_value value; + } u; +}; + +/** + * struct optee_msg_arg - call argument + * @cmd: Command, one of OPTEE_MSG_CMD_* or OPTEE_MSG_RPC_CMD_* + * @func: Trusted Application function, specific to the Trusted Application, + * used if cmd == OPTEE_MSG_CMD_INVOKE_COMMAND + * @session: In parameter for all OPTEE_MSG_CMD_* except + * OPTEE_MSG_CMD_OPEN_SESSION where it's an output parameter instead + * @cancel_id: Cancellation id, a unique value to identify this request + * @ret: return value + * @ret_origin: origin of the return value + * @num_params: number of parameters supplied to the OS Command + * @params: the parameters supplied to the OS Command + * + * All normal calls to Trusted OS uses this struct. If cmd requires further + * information than what these field holds it can be passed as a parameter + * tagged as meta (setting the OPTEE_MSG_ATTR_META bit in corresponding + * attrs field). All parameters tagged as meta has to come first. + * + * Temp memref parameters can be fragmented if supported by the Trusted OS + * (when optee_smc.h is bearer of this protocol this is indicated with + * OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM). If a logical memref parameter is + * fragmented then has all but the last fragment the + * OPTEE_MSG_ATTR_FRAGMENT bit set in attrs. Even if a memref is fragmented + * it will still be presented as a single logical memref to the Trusted + * Application. + */ +struct optee_msg_arg { + u32 cmd; + u32 func; + u32 session; + u32 cancel_id; + u32 pad; + u32 ret; + u32 ret_origin; + u32 num_params; + + /* num_params tells the actual number of element in params */ + struct optee_msg_param params[0]; +}; + +/** + * OPTEE_MSG_GET_ARG_SIZE - return size of struct optee_msg_arg + * + * @num_params: Number of parameters embedded in the struct optee_msg_arg + * + * Returns the size of the struct optee_msg_arg together with the number + * of embedded parameters. + */ +#define OPTEE_MSG_GET_ARG_SIZE(num_params) \ + (sizeof(struct optee_msg_arg) + \ + sizeof(struct optee_msg_param) * (num_params)) + +/***************************************************************************** + * Part 2 - requests from normal world + *****************************************************************************/ + +/* + * Return the following UID if using API specified in this file without + * further extensions: + * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. + * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, + * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + */ +#define OPTEE_MSG_UID_0 0x384fb3e0 +#define OPTEE_MSG_UID_1 0xe7f811e3 +#define OPTEE_MSG_UID_2 0xaf630002 +#define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 + +/* + * Returns 2.0 if using API specified in this file without further + * extensions. Represented in 2 32-bit words in OPTEE_MSG_REVISION_MAJOR + * and OPTEE_MSG_REVISION_MINOR + */ +#define OPTEE_MSG_REVISION_MAJOR 2 +#define OPTEE_MSG_REVISION_MINOR 0 +#define OPTEE_MSG_FUNCID_CALLS_REVISION 0xFF03 + +/* + * Get UUID of Trusted OS. + * + * Used by non-secure world to figure out which Trusted OS is installed. + * Note that returned UUID is the UUID of the Trusted OS, not of the API. + * + * Returns UUID in 4 32-bit words in the same way as + * OPTEE_MSG_FUNCID_CALLS_UID described above. + */ +#define OPTEE_MSG_OS_OPTEE_UUID_0 0x486178e0 +#define OPTEE_MSG_OS_OPTEE_UUID_1 0xe7f811e3 +#define OPTEE_MSG_OS_OPTEE_UUID_2 0xbc5e0002 +#define OPTEE_MSG_OS_OPTEE_UUID_3 0xa5d5c51b +#define OPTEE_MSG_FUNCID_GET_OS_UUID 0x0000 + +/* + * Get revision of Trusted OS. + * + * Used by non-secure world to figure out which version of the Trusted OS + * is installed. Note that the returned revision is the revision of the + * Trusted OS, not of the API. + * + * Returns revision in 2 32-bit words in the same way as + * OPTEE_MSG_CALLS_REVISION described above. + */ +#define OPTEE_MSG_FUNCID_GET_OS_REVISION 0x0001 + +/* + * Do a secure call with struct optee_msg_arg as argument + * The OPTEE_MSG_CMD_* below defines what goes in struct optee_msg_arg::cmd + * + * OPTEE_MSG_CMD_OPEN_SESSION opens a session to a Trusted Application. + * The first two parameters are tagged as meta, holding two value + * parameters to pass the following information: + * param[0].u.value.a-b uuid of Trusted Application + * param[1].u.value.a-b uuid of Client + * param[1].u.value.c Login class of client OPTEE_MSG_LOGIN_* + * + * OPTEE_MSG_CMD_INVOKE_COMMAND invokes a command a previously opened + * session to a Trusted Application. struct optee_msg_arg::func is Trusted + * Application function, specific to the Trusted Application. + * + * OPTEE_MSG_CMD_CLOSE_SESSION closes a previously opened session to + * Trusted Application. + * + * OPTEE_MSG_CMD_CANCEL cancels a currently invoked command. + * + * OPTEE_MSG_CMD_REGISTER_SHM registers a shared memory reference. The + * information is passed as: + * [in] param[0].attr OPTEE_MSG_ATTR_TYPE_TMEM_INPUT + * [| OPTEE_MSG_ATTR_FRAGMENT] + * [in] param[0].u.tmem.buf_ptr physical address (of first fragment) + * [in] param[0].u.tmem.size size (of first fragment) + * [in] param[0].u.tmem.shm_ref holds shared memory reference + * ... + * The shared memory can optionally be fragmented, temp memrefs can follow + * each other with all but the last with the OPTEE_MSG_ATTR_FRAGMENT bit set. + * + * OPTEE_MSG_CMD_UNREGISTER_SHM unregisteres a previously registered shared + * memory reference. The information is passed as: + * [in] param[0].attr OPTEE_MSG_ATTR_TYPE_RMEM_INPUT + * [in] param[0].u.rmem.shm_ref holds shared memory reference + * [in] param[0].u.rmem.offs 0 + * [in] param[0].u.rmem.size 0 + */ +#define OPTEE_MSG_CMD_OPEN_SESSION 0 +#define OPTEE_MSG_CMD_INVOKE_COMMAND 1 +#define OPTEE_MSG_CMD_CLOSE_SESSION 2 +#define OPTEE_MSG_CMD_CANCEL 3 +#define OPTEE_MSG_CMD_REGISTER_SHM 4 +#define OPTEE_MSG_CMD_UNREGISTER_SHM 5 +#define OPTEE_MSG_FUNCID_CALL_WITH_ARG 0x0004 + +/***************************************************************************** + * Part 3 - Requests from secure world, RPC + *****************************************************************************/ + +/* + * All RPC is done with a struct optee_msg_arg as bearer of information, + * struct optee_msg_arg::arg holds values defined by OPTEE_MSG_RPC_CMD_* below + * + * RPC communication with tee-supplicant is reversed compared to normal + * client communication desribed above. The supplicant receives requests + * and sends responses. + */ + +/* + * Load a TA into memory, defined in tee-supplicant + */ +#define OPTEE_MSG_RPC_CMD_LOAD_TA 0 + +/* + * Reserved + */ +#define OPTEE_MSG_RPC_CMD_RPMB 1 + +/* + * File system access, defined in tee-supplicant + */ +#define OPTEE_MSG_RPC_CMD_FS 2 + +/* + * Get time + * + * Returns number of seconds and nano seconds since the Epoch, + * 1970-01-01 00:00:00 +0000 (UTC). + * + * [out] param[0].u.value.a Number of seconds + * [out] param[0].u.value.b Number of nano seconds. + */ +#define OPTEE_MSG_RPC_CMD_GET_TIME 3 + +/* + * Wait queue primitive, helper for secure world to implement a wait queue. + * + * If secure world need to wait for a secure world mutex it issues a sleep + * request instead of spinning in secure world. Conversely is a wakeup + * request issued when a secure world mutex with a thread waiting thread is + * unlocked. + * + * Waiting on a key + * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP + * [in] param[0].u.value.b wait key + * + * Waking up a key + * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP + * [in] param[0].u.value.b wakeup key + */ +#define OPTEE_MSG_RPC_CMD_WAIT_QUEUE 4 +#define OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP 0 +#define OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP 1 + +/* + * Suspend execution + * + * [in] param[0].value .a number of milliseconds to suspend + */ +#define OPTEE_MSG_RPC_CMD_SUSPEND 5 + +/* + * Allocate a piece of shared memory + * + * Shared memory can optionally be fragmented, to support that additional + * spare param entries are allocated to make room for eventual fragments. + * The spare param entries has .attr = OPTEE_MSG_ATTR_TYPE_NONE when + * unused. All returned temp memrefs except the last should have the + * OPTEE_MSG_ATTR_FRAGMENT bit set in the attr field. + * + * [in] param[0].u.value.a type of memory one of + * OPTEE_MSG_RPC_SHM_TYPE_* below + * [in] param[0].u.value.b requested size + * [in] param[0].u.value.c required alignment + * + * [out] param[0].u.tmem.buf_ptr physical address (of first fragment) + * [out] param[0].u.tmem.size size (of first fragment) + * [out] param[0].u.tmem.shm_ref shared memory reference + * ... + * [out] param[n].u.tmem.buf_ptr physical address + * [out] param[n].u.tmem.size size + * [out] param[n].u.tmem.shm_ref shared memory reference (same value + * as in param[n-1].u.tmem.shm_ref) + */ +#define OPTEE_MSG_RPC_CMD_SHM_ALLOC 6 +/* Memory that can be shared with a non-secure user space application */ +#define OPTEE_MSG_RPC_SHM_TYPE_APPL 0 +/* Memory only shared with non-secure kernel */ +#define OPTEE_MSG_RPC_SHM_TYPE_KERNEL 1 + +/* + * Free shared memory previously allocated with OPTEE_MSG_RPC_CMD_SHM_ALLOC + * + * [in] param[0].u.value.a type of memory one of + * OPTEE_MSG_RPC_SHM_TYPE_* above + * [in] param[0].u.value.b value of shared memory reference + * returned in param[0].u.tmem.shm_ref + * above + */ +#define OPTEE_MSG_RPC_CMD_SHM_FREE 7 + +#endif /* _OPTEE_MSG_H */ diff --git a/xen/arch/arm/tee/optee_smc.h b/xen/arch/arm/tee/optee_smc.h new file mode 100644 index 0000000..92f4d54 --- /dev/null +++ b/xen/arch/arm/tee/optee_smc.h @@ -0,0 +1,457 @@ +/* + * Copyright (c) 2015-2016, Linaro Limited + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + * this list of conditions and the following disclaimer in the documentation + * and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ +#ifndef OPTEE_SMC_H +#define OPTEE_SMC_H + +#include <asm/smccc.h> +#include <xen/bitops.h> + +#define OPTEE_SMC_STD_CALL_VAL(func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_CONV_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS, (func_num)) +#define OPTEE_SMC_FAST_CALL_VAL(func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_CONV_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS, (func_num)) + +/* + * Function specified by SMC Calling convention. + */ +#define OPTEE_SMC_FUNCID_CALLS_COUNT 0xFF00 +#define OPTEE_SMC_CALLS_COUNT \ + ARM_SMCCC_CALL_VAL(OPTEE_SMC_FAST_CALL, SMCCC_SMC_32, \ + SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_CALLS_COUNT) + +/* + * Normal cached memory (write-back), shareable for SMP systems and not + * shareable for UP systems. + */ +#define OPTEE_SMC_SHM_CACHED 1 + +/* + * a0..a7 is used as register names in the descriptions below, on arm32 + * that translates to r0..r7 and on arm64 to w0..w7. In both cases it's + * 32-bit registers. + */ + +/* + * Function specified by SMC Calling convention + * + * Return one of the following UIDs if using API specified in this file + * without further extentions: + * 65cb6b93-af0c-4617-8ed6-644a8d1140f8 + * see also OPTEE_SMC_UID_* in optee_msg.h + */ +#define OPTEE_SMC_FUNCID_CALLS_UID OPTEE_MSG_FUNCID_CALLS_UID +#define OPTEE_SMC_CALLS_UID \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_CONV_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_CALLS_UID) + +/* + * Function specified by SMC Calling convention + * + * Returns 2.0 if using API specified in this file without further extentions. + * see also OPTEE_MSG_REVISION_* in optee_msg.h + */ +#define OPTEE_SMC_FUNCID_CALLS_REVISION OPTEE_MSG_FUNCID_CALLS_REVISION +#define OPTEE_SMC_CALLS_REVISION \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_CONV_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_CALLS_REVISION) + +struct optee_smc_calls_revision_result { + unsigned long major; + unsigned long minor; + unsigned long reserved0; + unsigned long reserved1; +}; + +/* + * Get UUID of Trusted OS. + * + * Used by non-secure world to figure out which Trusted OS is installed. + * Note that returned UUID is the UUID of the Trusted OS, not of the API. + * + * Returns UUID in a0-4 in the same way as OPTEE_SMC_CALLS_UID + * described above. + */ +#define OPTEE_SMC_FUNCID_GET_OS_UUID OPTEE_MSG_FUNCID_GET_OS_UUID +#define OPTEE_SMC_CALL_GET_OS_UUID \ + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_UUID) + +/* + * Get revision of Trusted OS. + * + * Used by non-secure world to figure out which version of the Trusted OS + * is installed. Note that the returned revision is the revision of the + * Trusted OS, not of the API. + * + * Returns revision in a0-1 in the same way as OPTEE_SMC_CALLS_REVISION + * described above. + */ +#define OPTEE_SMC_FUNCID_GET_OS_REVISION OPTEE_MSG_FUNCID_GET_OS_REVISION +#define OPTEE_SMC_CALL_GET_OS_REVISION \ + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_REVISION) + +/* + * Call with struct optee_msg_arg as argument + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC*CALL_WITH_ARG + * a1 Upper 32bit of a 64bit physical pointer to a struct optee_msg_arg + * a2 Lower 32bit of a 64bit physical pointer to a struct optee_msg_arg + * a3 Cache settings, not used if physical pointer is in a predefined shared + * memory area else per OPTEE_SMC_SHM_* + * a4-6 Not used + * a7 Hypervisor Client ID register + * + * Normal return register usage: + * a0 Return value, OPTEE_SMC_RETURN_* + * a1-3 Not used + * a4-7 Preserved + * + * OPTEE_SMC_RETURN_ETHREAD_LIMIT return register usage: + * a0 Return value, OPTEE_SMC_RETURN_ETHREAD_LIMIT + * a1-3 Preserved + * a4-7 Preserved + * + * RPC return register usage: + * a0 Return value, OPTEE_SMC_RETURN_IS_RPC(val) + * a1-2 RPC parameters + * a3-7 Resume information, must be preserved + * + * Possible return values: + * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION Trusted OS does not recognize this + * function. + * OPTEE_SMC_RETURN_OK Call completed, result updated in + * the previously supplied struct + * optee_msg_arg. + * OPTEE_SMC_RETURN_ETHREAD_LIMIT Number of Trusted OS threads exceeded, + * try again later. + * OPTEE_SMC_RETURN_EBADADDR Bad physcial pointer to struct + * optee_msg_arg. + * OPTEE_SMC_RETURN_EBADCMD Bad/unknown cmd in struct optee_msg_arg + * OPTEE_SMC_RETURN_IS_RPC() Call suspended by RPC call to normal + * world. + */ +#define OPTEE_SMC_FUNCID_CALL_WITH_ARG OPTEE_MSG_FUNCID_CALL_WITH_ARG +#define OPTEE_SMC_CALL_WITH_ARG \ + OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_CALL_WITH_ARG) + +/* + * Get Shared Memory Config + * + * Returns the Secure/Non-secure shared memory config. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_GET_SHM_CONFIG + * a1-6 Not used + * a7 Hypervisor Client ID register + * + * Have config return register usage: + * a0 OPTEE_SMC_RETURN_OK + * a1 Physical address of start of SHM + * a2 Size of of SHM + * a3 Cache settings of memory, as defined by the + * OPTEE_SMC_SHM_* values above + * a4-7 Preserved + * + * Not available register usage: + * a0 OPTEE_SMC_RETURN_ENOTAVAIL + * a1-3 Not used + * a4-7 Preserved + */ +#define OPTEE_SMC_FUNCID_GET_SHM_CONFIG 7 +#define OPTEE_SMC_GET_SHM_CONFIG \ + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_SHM_CONFIG) + +struct optee_smc_get_shm_config_result { + unsigned long status; + unsigned long start; + unsigned long size; + unsigned long settings; +}; + +/* + * Exchanges capabilities between normal world and secure world + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_EXCHANGE_CAPABILITIES + * a1 bitfield of normal world capabilities OPTEE_SMC_NSEC_CAP_* + * a2-6 Not used + * a7 Hypervisor Client ID register + * + * Normal return register usage: + * a0 OPTEE_SMC_RETURN_OK + * a1 bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_* + * a2-7 Preserved + * + * Error return register usage: + * a0 OPTEE_SMC_RETURN_ENOTAVAIL, can't use the capabilities from normal world + * a1 bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_* + * a2-7 Preserved + */ +/* Normal world works as a uniprocessor system */ +#define OPTEE_SMC_NSEC_CAP_UNIPROCESSOR BIT(0) +/* Secure world has reserved shared memory for normal world to use */ +#define OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM BIT(0) +/* Secure world can communicate via previously unregistered shared memory */ +#define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM BIT(1) + +/* + * Secure world supports commands "register/unregister shared memory", + * secure world accepts command buffers located in any parts of non-secure RAM + */ +#define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM BIT(2) + +#define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9 +#define OPTEE_SMC_EXCHANGE_CAPABILITIES \ + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES) + +struct optee_smc_exchange_capabilities_result { + unsigned long status; + unsigned long capabilities; + unsigned long reserved0; + unsigned long reserved1; +}; + +/* + * Disable and empties cache of shared memory objects + * + * Secure world can cache frequently used shared memory objects, for + * example objects used as RPC arguments. When secure world is idle this + * function returns one shared memory reference to free. To disable the + * cache and free all cached objects this function has to be called until + * it returns OPTEE_SMC_RETURN_ENOTAVAIL. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_DISABLE_SHM_CACHE + * a1-6 Not used + * a7 Hypervisor Client ID register + * + * Normal return register usage: + * a0 OPTEE_SMC_RETURN_OK + * a1 Upper 32bit of a 64bit Shared memory cookie + * a2 Lower 32bit of a 64bit Shared memory cookie + * a3-7 Preserved + * + * Cache empty return register usage: + * a0 OPTEE_SMC_RETURN_ENOTAVAIL + * a1-7 Preserved + * + * Not idle return register usage: + * a0 OPTEE_SMC_RETURN_EBUSY + * a1-7 Preserved + */ +#define OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE 10 +#define OPTEE_SMC_DISABLE_SHM_CACHE \ + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE) + +struct optee_smc_disable_shm_cache_result { + unsigned long status; + unsigned long shm_upper32; + unsigned long shm_lower32; + unsigned long reserved0; +}; + +/* + * Enable cache of shared memory objects + * + * Secure world can cache frequently used shared memory objects, for + * example objects used as RPC arguments. When secure world is idle this + * function returns OPTEE_SMC_RETURN_OK and the cache is enabled. If + * secure world isn't idle OPTEE_SMC_RETURN_EBUSY is returned. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_ENABLE_SHM_CACHE + * a1-6 Not used + * a7 Hypervisor Client ID register + * + * Normal return register usage: + * a0 OPTEE_SMC_RETURN_OK + * a1-7 Preserved + * + * Not idle return register usage: + * a0 OPTEE_SMC_RETURN_EBUSY + * a1-7 Preserved + */ +#define OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE 11 +#define OPTEE_SMC_ENABLE_SHM_CACHE \ + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE) + +/* + * Resume from RPC (for example after processing a foreign interrupt) + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC + * a1-3 Value of a1-3 when OPTEE_SMC_CALL_WITH_ARG returned + * OPTEE_SMC_RETURN_RPC in a0 + * + * Return register usage is the same as for OPTEE_SMC_*CALL_WITH_ARG above. + * + * Possible return values + * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION Trusted OS does not recognize this + * function. + * OPTEE_SMC_RETURN_OK Original call completed, result + * updated in the previously supplied. + * struct optee_msg_arg + * OPTEE_SMC_RETURN_RPC Call suspended by RPC call to normal + * world. + * OPTEE_SMC_RETURN_ERESUME Resume failed, the opaque resume + * information was corrupt. + */ +#define OPTEE_SMC_FUNCID_RETURN_FROM_RPC 3 +#define OPTEE_SMC_CALL_RETURN_FROM_RPC \ + OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_RETURN_FROM_RPC) + +#define OPTEE_SMC_RETURN_RPC_PREFIX_MASK 0xFFFF0000 +#define OPTEE_SMC_RETURN_RPC_PREFIX 0xFFFF0000 +#define OPTEE_SMC_RETURN_RPC_FUNC_MASK 0x0000FFFF + +#define OPTEE_SMC_RETURN_GET_RPC_FUNC(ret) \ + ((ret) & OPTEE_SMC_RETURN_RPC_FUNC_MASK) + +#define OPTEE_SMC_RPC_VAL(func) ((func) | OPTEE_SMC_RETURN_RPC_PREFIX) + +/* + * Allocate memory for RPC parameter passing. The memory is used to hold a + * struct optee_msg_arg. + * + * "Call" register usage: + * a0 This value, OPTEE_SMC_RETURN_RPC_ALLOC + * a1 Size in bytes of required argument memory + * a2 Not used + * a3 Resume information, must be preserved + * a4-5 Not used + * a6-7 Resume information, must be preserved + * + * "Return" register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. + * a1 Upper 32bits of 64bit physical pointer to allocated + * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't + * be allocated. + * a2 Lower 32bits of 64bit physical pointer to allocated + * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't + * be allocated + * a3 Preserved + * a4 Upper 32bits of 64bit Shared memory cookie used when freeing + * the memory or doing an RPC + * a5 Lower 32bits of 64bit Shared memory cookie used when freeing + * the memory or doing an RPC + * a6-7 Preserved + */ +#define OPTEE_SMC_RPC_FUNC_ALLOC 0 +#define OPTEE_SMC_RETURN_RPC_ALLOC \ + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_ALLOC) + +/* + * Free memory previously allocated by OPTEE_SMC_RETURN_RPC_ALLOC + * + * "Call" register usage: + * a0 This value, OPTEE_SMC_RETURN_RPC_FREE + * a1 Upper 32bits of 64bit shared memory cookie belonging to this + * argument memory + * a2 Lower 32bits of 64bit shared memory cookie belonging to this + * argument memory + * a3-7 Resume information, must be preserved + * + * "Return" register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. + * a1-2 Not used + * a3-7 Preserved + */ +#define OPTEE_SMC_RPC_FUNC_FREE 2 +#define OPTEE_SMC_RETURN_RPC_FREE \ + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FREE) + +/* + * Deliver foreign interrupt to normal world. + * + * "Call" register usage: + * a0 OPTEE_SMC_RETURN_RPC_FOREIGN_INTR + * a1-7 Resume information, must be preserved + * + * "Return" register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. + * a1-7 Preserved + */ +#define OPTEE_SMC_RPC_FUNC_FOREIGN_INTR 4 +#define OPTEE_SMC_RETURN_RPC_FOREIGN_INTR \ + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FOREIGN_INTR) + +/* + * Do an RPC request. The supplied struct optee_msg_arg tells which + * request to do and the parameters for the request. The following fields + * are used (the rest are unused): + * - cmd the Request ID + * - ret return value of the request, filled in by normal world + * - num_params number of parameters for the request + * - params the parameters + * - param_attrs attributes of the parameters + * + * "Call" register usage: + * a0 OPTEE_SMC_RETURN_RPC_CMD + * a1 Upper 32bit of a 64bit Shared memory cookie holding a + * struct optee_msg_arg, must be preserved, only the data should + * be updated + * a2 Lower 32bit of a 64bit Shared memory cookie holding a + * struct optee_msg_arg, must be preserved, only the data should + * be updated + * a3-7 Resume information, must be preserved + * + * "Return" register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. + * a1-2 Not used + * a3-7 Preserved + */ +#define OPTEE_SMC_RPC_FUNC_CMD 5 +#define OPTEE_SMC_RETURN_RPC_CMD \ + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_CMD) + +/* Returned in a0 */ +#define OPTEE_SMC_RETURN_UNKNOWN_FUNCTION 0xFFFFFFFF + +/* Returned in a0 only from Trusted OS functions */ +#define OPTEE_SMC_RETURN_OK 0x0 +#define OPTEE_SMC_RETURN_ETHREAD_LIMIT 0x1 +#define OPTEE_SMC_RETURN_EBUSY 0x2 +#define OPTEE_SMC_RETURN_ERESUME 0x3 +#define OPTEE_SMC_RETURN_EBADADDR 0x4 +#define OPTEE_SMC_RETURN_EBADCMD 0x5 +#define OPTEE_SMC_RETURN_ENOMEM 0x6 +#define OPTEE_SMC_RETURN_ENOTAVAIL 0x7 +#define OPTEE_SMC_RETURN_IS_RPC(ret) __optee_smc_return_is_rpc((ret)) + +static inline bool __optee_smc_return_is_rpc(u32 ret) +{ + return ret != OPTEE_SMC_RETURN_UNKNOWN_FUNCTION && + (ret & OPTEE_SMC_RETURN_RPC_PREFIX_MASK) == + OPTEE_SMC_RETURN_RPC_PREFIX; +} + +#endif /* OPTEE_SMC_H */ -- 2.7.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [RFC 3/4] arm: tee: add OP-TEE header files 2017-10-11 19:01 ` [RFC 3/4] arm: tee: add OP-TEE header files Volodymyr Babchuk @ 2017-10-16 14:04 ` Julien Grall 2017-10-17 16:24 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-16 14:04 UTC (permalink / raw) To: Volodymyr Babchuk, Stefano Stabellini, Julien Grall, xen-devel Hi Volodymyr, On 11/10/17 20:01, Volodymyr Babchuk wrote: > This header files describe protocol between OP-TEE and OP-TEE client > driver in Linux. They are needed for upcomient OP-TEE mediator, which > is added in the next patch. > Reason to add those headers in separate patch is to ease up review. > Those files were taken from linux tree (drivers/tee/optee/) and mangled > a bit to compile with XEN. > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > xen/arch/arm/tee/optee_msg.h | 444 +++++++++++++++++++++++++++++++++++++++++ > xen/arch/arm/tee/optee_smc.h | 457 +++++++++++++++++++++++++++++++++++++++++++ Headers should go in include/asm-arm/tee and not arch/arm. Cheers, > 2 files changed, 901 insertions(+) > create mode 100644 xen/arch/arm/tee/optee_msg.h > create mode 100644 xen/arch/arm/tee/optee_smc.h > > diff --git a/xen/arch/arm/tee/optee_msg.h b/xen/arch/arm/tee/optee_msg.h > new file mode 100644 > index 0000000..10747b2 > --- /dev/null > +++ b/xen/arch/arm/tee/optee_msg.h > @@ -0,0 +1,444 @@ > +/* > + * Copyright (c) 2015-2016, Linaro Limited > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions are met: > + * > + * 1. Redistributions of source code must retain the above copyright notice, > + * this list of conditions and the following disclaimer. > + * > + * 2. Redistributions in binary form must reproduce the above copyright notice, > + * this list of conditions and the following disclaimer in the documentation > + * and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > +#ifndef _OPTEE_MSG_H > +#define _OPTEE_MSG_H > + > +#include <xen/bitops.h> > +#include <xen/types.h> > + > +/* > + * This file defines the OP-TEE message protocol used to communicate > + * with an instance of OP-TEE running in secure world. > + * > + * This file is divided into three sections. > + * 1. Formatting of messages. > + * 2. Requests from normal world > + * 3. Requests from secure world, Remote Procedure Call (RPC), handled by > + * tee-supplicant. > + */ > + > +/***************************************************************************** > + * Part 1 - formatting of messages > + *****************************************************************************/ > + > +#define OPTEE_MSG_ATTR_TYPE_NONE 0x0 > +#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT 0x1 > +#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT 0x2 > +#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT 0x3 > +#define OPTEE_MSG_ATTR_TYPE_RMEM_INPUT 0x5 > +#define OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT 0x6 > +#define OPTEE_MSG_ATTR_TYPE_RMEM_INOUT 0x7 > +#define OPTEE_MSG_ATTR_TYPE_TMEM_INPUT 0x9 > +#define OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT 0xa > +#define OPTEE_MSG_ATTR_TYPE_TMEM_INOUT 0xb > + > +#define OPTEE_MSG_ATTR_TYPE_MASK GENMASK(7, 0) > + > +/* > + * Meta parameter to be absorbed by the Secure OS and not passed > + * to the Trusted Application. > + * > + * Currently only used with OPTEE_MSG_CMD_OPEN_SESSION. > + */ > +#define OPTEE_MSG_ATTR_META BIT(8) > + > +/* > + * Pointer to a list of pages used to register user-defined SHM buffer. > + * Used with OPTEE_MSG_ATTR_TYPE_TMEM_*. > + * buf_ptr should point to the beginning of the buffer. Buffer will contain > + * list of page addresses. OP-TEE core can reconstruct contiguous buffer from > + * that page addresses list. Page addresses are stored as 64 bit values. > + * Last entry on a page should point to the next page of buffer. > + * Every entry in buffer should point to a 4k page beginning (12 least > + * significant bits must be equal to zero). > + * > + * 12 least significant bints of optee_msg_param.u.tmem.buf_ptr should hold page > + * offset of the user buffer. > + * > + * So, entries should be placed like members of this structure: > + * > + * struct page_data { > + * uint64_t pages_array[OPTEE_MSG_NONCONTIG_PAGE_SIZE/sizeof(uint64_t) - 1]; > + * uint64_t next_page_data; > + * }; > + * > + * Structure is designed to exactly fit into the page size > + * OPTEE_MSG_NONCONTIG_PAGE_SIZE which is a standard 4KB page. > + * > + * The size of 4KB is chosen because this is the smallest page size for ARM > + * architectures. If REE uses larger pages, it should divide them to 4KB ones. > + */ > +#define OPTEE_MSG_ATTR_NONCONTIG BIT(9) > + > +/* > + * Memory attributes for caching passed with temp memrefs. The actual value > + * used is defined outside the message protocol with the exception of > + * OPTEE_MSG_ATTR_CACHE_PREDEFINED which means the attributes already > + * defined for the memory range should be used. If optee_smc.h is used as > + * bearer of this protocol OPTEE_SMC_SHM_* is used for values. > + */ > +#define OPTEE_MSG_ATTR_CACHE_SHIFT 16 > +#define OPTEE_MSG_ATTR_CACHE_MASK GENMASK(2, 0) > +#define OPTEE_MSG_ATTR_CACHE_PREDEFINED 0 > + > +/* > + * Same values as TEE_LOGIN_* from TEE Internal API > + */ > +#define OPTEE_MSG_LOGIN_PUBLIC 0x00000000 > +#define OPTEE_MSG_LOGIN_USER 0x00000001 > +#define OPTEE_MSG_LOGIN_GROUP 0x00000002 > +#define OPTEE_MSG_LOGIN_APPLICATION 0x00000004 > +#define OPTEE_MSG_LOGIN_APPLICATION_USER 0x00000005 > +#define OPTEE_MSG_LOGIN_APPLICATION_GROUP 0x00000006 > + > +/* > + * Page size used in non-contiguous buffer entries > + */ > +#define OPTEE_MSG_NONCONTIG_PAGE_SIZE 4096 > + > +/** > + * struct optee_msg_param_tmem - temporary memory reference parameter > + * @buf_ptr: Address of the buffer > + * @size: Size of the buffer > + * @shm_ref: Temporary shared memory reference, pointer to a struct tee_shm > + * > + * Secure and normal world communicates pointers as physical address > + * instead of the virtual address. This is because secure and normal world > + * have completely independent memory mapping. Normal world can even have a > + * hypervisor which need to translate the guest physical address (AKA IPA > + * in ARM documentation) to a real physical address before passing the > + * structure to secure world. > + */ > +struct optee_msg_param_tmem { > + u64 buf_ptr; > + u64 size; > + u64 shm_ref; > +}; > + > +/** > + * struct optee_msg_param_rmem - registered memory reference parameter > + * @offs: Offset into shared memory reference > + * @size: Size of the buffer > + * @shm_ref: Shared memory reference, pointer to a struct tee_shm > + */ > +struct optee_msg_param_rmem { > + u64 offs; > + u64 size; > + u64 shm_ref; > +}; > + > +/** > + * struct optee_msg_param_value - opaque value parameter > + * > + * Value parameters are passed unchecked between normal and secure world. > + */ > +struct optee_msg_param_value { > + u64 a; > + u64 b; > + u64 c; > +}; > + > +/** > + * struct optee_msg_param - parameter used together with struct optee_msg_arg > + * @attr: attributes > + * @tmem: parameter by temporary memory reference > + * @rmem: parameter by registered memory reference > + * @value: parameter by opaque value > + * > + * @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in > + * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value, > + * OPTEE_MSG_ATTR_TYPE_TMEM_* indicates @tmem and > + * OPTEE_MSG_ATTR_TYPE_RMEM_* indicates @rmem, > + * OPTEE_MSG_ATTR_TYPE_NONE indicates that none of the members are used. > + */ > +struct optee_msg_param { > + u64 attr; > + union { > + struct optee_msg_param_tmem tmem; > + struct optee_msg_param_rmem rmem; > + struct optee_msg_param_value value; > + } u; > +}; > + > +/** > + * struct optee_msg_arg - call argument > + * @cmd: Command, one of OPTEE_MSG_CMD_* or OPTEE_MSG_RPC_CMD_* > + * @func: Trusted Application function, specific to the Trusted Application, > + * used if cmd == OPTEE_MSG_CMD_INVOKE_COMMAND > + * @session: In parameter for all OPTEE_MSG_CMD_* except > + * OPTEE_MSG_CMD_OPEN_SESSION where it's an output parameter instead > + * @cancel_id: Cancellation id, a unique value to identify this request > + * @ret: return value > + * @ret_origin: origin of the return value > + * @num_params: number of parameters supplied to the OS Command > + * @params: the parameters supplied to the OS Command > + * > + * All normal calls to Trusted OS uses this struct. If cmd requires further > + * information than what these field holds it can be passed as a parameter > + * tagged as meta (setting the OPTEE_MSG_ATTR_META bit in corresponding > + * attrs field). All parameters tagged as meta has to come first. > + * > + * Temp memref parameters can be fragmented if supported by the Trusted OS > + * (when optee_smc.h is bearer of this protocol this is indicated with > + * OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM). If a logical memref parameter is > + * fragmented then has all but the last fragment the > + * OPTEE_MSG_ATTR_FRAGMENT bit set in attrs. Even if a memref is fragmented > + * it will still be presented as a single logical memref to the Trusted > + * Application. > + */ > +struct optee_msg_arg { > + u32 cmd; > + u32 func; > + u32 session; > + u32 cancel_id; > + u32 pad; > + u32 ret; > + u32 ret_origin; > + u32 num_params; > + > + /* num_params tells the actual number of element in params */ > + struct optee_msg_param params[0]; > +}; > + > +/** > + * OPTEE_MSG_GET_ARG_SIZE - return size of struct optee_msg_arg > + * > + * @num_params: Number of parameters embedded in the struct optee_msg_arg > + * > + * Returns the size of the struct optee_msg_arg together with the number > + * of embedded parameters. > + */ > +#define OPTEE_MSG_GET_ARG_SIZE(num_params) \ > + (sizeof(struct optee_msg_arg) + \ > + sizeof(struct optee_msg_param) * (num_params)) > + > +/***************************************************************************** > + * Part 2 - requests from normal world > + *****************************************************************************/ > + > +/* > + * Return the following UID if using API specified in this file without > + * further extensions: > + * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. > + * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, > + * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. > + */ > +#define OPTEE_MSG_UID_0 0x384fb3e0 > +#define OPTEE_MSG_UID_1 0xe7f811e3 > +#define OPTEE_MSG_UID_2 0xaf630002 > +#define OPTEE_MSG_UID_3 0xa5d5c51b > +#define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 > + > +/* > + * Returns 2.0 if using API specified in this file without further > + * extensions. Represented in 2 32-bit words in OPTEE_MSG_REVISION_MAJOR > + * and OPTEE_MSG_REVISION_MINOR > + */ > +#define OPTEE_MSG_REVISION_MAJOR 2 > +#define OPTEE_MSG_REVISION_MINOR 0 > +#define OPTEE_MSG_FUNCID_CALLS_REVISION 0xFF03 > + > +/* > + * Get UUID of Trusted OS. > + * > + * Used by non-secure world to figure out which Trusted OS is installed. > + * Note that returned UUID is the UUID of the Trusted OS, not of the API. > + * > + * Returns UUID in 4 32-bit words in the same way as > + * OPTEE_MSG_FUNCID_CALLS_UID described above. > + */ > +#define OPTEE_MSG_OS_OPTEE_UUID_0 0x486178e0 > +#define OPTEE_MSG_OS_OPTEE_UUID_1 0xe7f811e3 > +#define OPTEE_MSG_OS_OPTEE_UUID_2 0xbc5e0002 > +#define OPTEE_MSG_OS_OPTEE_UUID_3 0xa5d5c51b > +#define OPTEE_MSG_FUNCID_GET_OS_UUID 0x0000 > + > +/* > + * Get revision of Trusted OS. > + * > + * Used by non-secure world to figure out which version of the Trusted OS > + * is installed. Note that the returned revision is the revision of the > + * Trusted OS, not of the API. > + * > + * Returns revision in 2 32-bit words in the same way as > + * OPTEE_MSG_CALLS_REVISION described above. > + */ > +#define OPTEE_MSG_FUNCID_GET_OS_REVISION 0x0001 > + > +/* > + * Do a secure call with struct optee_msg_arg as argument > + * The OPTEE_MSG_CMD_* below defines what goes in struct optee_msg_arg::cmd > + * > + * OPTEE_MSG_CMD_OPEN_SESSION opens a session to a Trusted Application. > + * The first two parameters are tagged as meta, holding two value > + * parameters to pass the following information: > + * param[0].u.value.a-b uuid of Trusted Application > + * param[1].u.value.a-b uuid of Client > + * param[1].u.value.c Login class of client OPTEE_MSG_LOGIN_* > + * > + * OPTEE_MSG_CMD_INVOKE_COMMAND invokes a command a previously opened > + * session to a Trusted Application. struct optee_msg_arg::func is Trusted > + * Application function, specific to the Trusted Application. > + * > + * OPTEE_MSG_CMD_CLOSE_SESSION closes a previously opened session to > + * Trusted Application. > + * > + * OPTEE_MSG_CMD_CANCEL cancels a currently invoked command. > + * > + * OPTEE_MSG_CMD_REGISTER_SHM registers a shared memory reference. The > + * information is passed as: > + * [in] param[0].attr OPTEE_MSG_ATTR_TYPE_TMEM_INPUT > + * [| OPTEE_MSG_ATTR_FRAGMENT] > + * [in] param[0].u.tmem.buf_ptr physical address (of first fragment) > + * [in] param[0].u.tmem.size size (of first fragment) > + * [in] param[0].u.tmem.shm_ref holds shared memory reference > + * ... > + * The shared memory can optionally be fragmented, temp memrefs can follow > + * each other with all but the last with the OPTEE_MSG_ATTR_FRAGMENT bit set. > + * > + * OPTEE_MSG_CMD_UNREGISTER_SHM unregisteres a previously registered shared > + * memory reference. The information is passed as: > + * [in] param[0].attr OPTEE_MSG_ATTR_TYPE_RMEM_INPUT > + * [in] param[0].u.rmem.shm_ref holds shared memory reference > + * [in] param[0].u.rmem.offs 0 > + * [in] param[0].u.rmem.size 0 > + */ > +#define OPTEE_MSG_CMD_OPEN_SESSION 0 > +#define OPTEE_MSG_CMD_INVOKE_COMMAND 1 > +#define OPTEE_MSG_CMD_CLOSE_SESSION 2 > +#define OPTEE_MSG_CMD_CANCEL 3 > +#define OPTEE_MSG_CMD_REGISTER_SHM 4 > +#define OPTEE_MSG_CMD_UNREGISTER_SHM 5 > +#define OPTEE_MSG_FUNCID_CALL_WITH_ARG 0x0004 > + > +/***************************************************************************** > + * Part 3 - Requests from secure world, RPC > + *****************************************************************************/ > + > +/* > + * All RPC is done with a struct optee_msg_arg as bearer of information, > + * struct optee_msg_arg::arg holds values defined by OPTEE_MSG_RPC_CMD_* below > + * > + * RPC communication with tee-supplicant is reversed compared to normal > + * client communication desribed above. The supplicant receives requests > + * and sends responses. > + */ > + > +/* > + * Load a TA into memory, defined in tee-supplicant > + */ > +#define OPTEE_MSG_RPC_CMD_LOAD_TA 0 > + > +/* > + * Reserved > + */ > +#define OPTEE_MSG_RPC_CMD_RPMB 1 > + > +/* > + * File system access, defined in tee-supplicant > + */ > +#define OPTEE_MSG_RPC_CMD_FS 2 > + > +/* > + * Get time > + * > + * Returns number of seconds and nano seconds since the Epoch, > + * 1970-01-01 00:00:00 +0000 (UTC). > + * > + * [out] param[0].u.value.a Number of seconds > + * [out] param[0].u.value.b Number of nano seconds. > + */ > +#define OPTEE_MSG_RPC_CMD_GET_TIME 3 > + > +/* > + * Wait queue primitive, helper for secure world to implement a wait queue. > + * > + * If secure world need to wait for a secure world mutex it issues a sleep > + * request instead of spinning in secure world. Conversely is a wakeup > + * request issued when a secure world mutex with a thread waiting thread is > + * unlocked. > + * > + * Waiting on a key > + * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP > + * [in] param[0].u.value.b wait key > + * > + * Waking up a key > + * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP > + * [in] param[0].u.value.b wakeup key > + */ > +#define OPTEE_MSG_RPC_CMD_WAIT_QUEUE 4 > +#define OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP 0 > +#define OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP 1 > + > +/* > + * Suspend execution > + * > + * [in] param[0].value .a number of milliseconds to suspend > + */ > +#define OPTEE_MSG_RPC_CMD_SUSPEND 5 > + > +/* > + * Allocate a piece of shared memory > + * > + * Shared memory can optionally be fragmented, to support that additional > + * spare param entries are allocated to make room for eventual fragments. > + * The spare param entries has .attr = OPTEE_MSG_ATTR_TYPE_NONE when > + * unused. All returned temp memrefs except the last should have the > + * OPTEE_MSG_ATTR_FRAGMENT bit set in the attr field. > + * > + * [in] param[0].u.value.a type of memory one of > + * OPTEE_MSG_RPC_SHM_TYPE_* below > + * [in] param[0].u.value.b requested size > + * [in] param[0].u.value.c required alignment > + * > + * [out] param[0].u.tmem.buf_ptr physical address (of first fragment) > + * [out] param[0].u.tmem.size size (of first fragment) > + * [out] param[0].u.tmem.shm_ref shared memory reference > + * ... > + * [out] param[n].u.tmem.buf_ptr physical address > + * [out] param[n].u.tmem.size size > + * [out] param[n].u.tmem.shm_ref shared memory reference (same value > + * as in param[n-1].u.tmem.shm_ref) > + */ > +#define OPTEE_MSG_RPC_CMD_SHM_ALLOC 6 > +/* Memory that can be shared with a non-secure user space application */ > +#define OPTEE_MSG_RPC_SHM_TYPE_APPL 0 > +/* Memory only shared with non-secure kernel */ > +#define OPTEE_MSG_RPC_SHM_TYPE_KERNEL 1 > + > +/* > + * Free shared memory previously allocated with OPTEE_MSG_RPC_CMD_SHM_ALLOC > + * > + * [in] param[0].u.value.a type of memory one of > + * OPTEE_MSG_RPC_SHM_TYPE_* above > + * [in] param[0].u.value.b value of shared memory reference > + * returned in param[0].u.tmem.shm_ref > + * above > + */ > +#define OPTEE_MSG_RPC_CMD_SHM_FREE 7 > + > +#endif /* _OPTEE_MSG_H */ > diff --git a/xen/arch/arm/tee/optee_smc.h b/xen/arch/arm/tee/optee_smc.h > new file mode 100644 > index 0000000..92f4d54 > --- /dev/null > +++ b/xen/arch/arm/tee/optee_smc.h > @@ -0,0 +1,457 @@ > +/* > + * Copyright (c) 2015-2016, Linaro Limited > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions are met: > + * > + * 1. Redistributions of source code must retain the above copyright notice, > + * this list of conditions and the following disclaimer. > + * > + * 2. Redistributions in binary form must reproduce the above copyright notice, > + * this list of conditions and the following disclaimer in the documentation > + * and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > +#ifndef OPTEE_SMC_H > +#define OPTEE_SMC_H > + > +#include <asm/smccc.h> > +#include <xen/bitops.h> > + > +#define OPTEE_SMC_STD_CALL_VAL(func_num) \ > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_CONV_32, \ > + ARM_SMCCC_OWNER_TRUSTED_OS, (func_num)) > +#define OPTEE_SMC_FAST_CALL_VAL(func_num) \ > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_CONV_32, \ > + ARM_SMCCC_OWNER_TRUSTED_OS, (func_num)) > + > +/* > + * Function specified by SMC Calling convention. > + */ > +#define OPTEE_SMC_FUNCID_CALLS_COUNT 0xFF00 > +#define OPTEE_SMC_CALLS_COUNT \ > + ARM_SMCCC_CALL_VAL(OPTEE_SMC_FAST_CALL, SMCCC_SMC_32, \ > + SMCCC_OWNER_TRUSTED_OS_END, \ > + OPTEE_SMC_FUNCID_CALLS_COUNT) > + > +/* > + * Normal cached memory (write-back), shareable for SMP systems and not > + * shareable for UP systems. > + */ > +#define OPTEE_SMC_SHM_CACHED 1 > + > +/* > + * a0..a7 is used as register names in the descriptions below, on arm32 > + * that translates to r0..r7 and on arm64 to w0..w7. In both cases it's > + * 32-bit registers. > + */ > + > +/* > + * Function specified by SMC Calling convention > + * > + * Return one of the following UIDs if using API specified in this file > + * without further extentions: > + * 65cb6b93-af0c-4617-8ed6-644a8d1140f8 > + * see also OPTEE_SMC_UID_* in optee_msg.h > + */ > +#define OPTEE_SMC_FUNCID_CALLS_UID OPTEE_MSG_FUNCID_CALLS_UID > +#define OPTEE_SMC_CALLS_UID \ > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_CONV_32, \ > + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ > + OPTEE_SMC_FUNCID_CALLS_UID) > + > +/* > + * Function specified by SMC Calling convention > + * > + * Returns 2.0 if using API specified in this file without further extentions. > + * see also OPTEE_MSG_REVISION_* in optee_msg.h > + */ > +#define OPTEE_SMC_FUNCID_CALLS_REVISION OPTEE_MSG_FUNCID_CALLS_REVISION > +#define OPTEE_SMC_CALLS_REVISION \ > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_CONV_32, \ > + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ > + OPTEE_SMC_FUNCID_CALLS_REVISION) > + > +struct optee_smc_calls_revision_result { > + unsigned long major; > + unsigned long minor; > + unsigned long reserved0; > + unsigned long reserved1; > +}; > + > +/* > + * Get UUID of Trusted OS. > + * > + * Used by non-secure world to figure out which Trusted OS is installed. > + * Note that returned UUID is the UUID of the Trusted OS, not of the API. > + * > + * Returns UUID in a0-4 in the same way as OPTEE_SMC_CALLS_UID > + * described above. > + */ > +#define OPTEE_SMC_FUNCID_GET_OS_UUID OPTEE_MSG_FUNCID_GET_OS_UUID > +#define OPTEE_SMC_CALL_GET_OS_UUID \ > + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_UUID) > + > +/* > + * Get revision of Trusted OS. > + * > + * Used by non-secure world to figure out which version of the Trusted OS > + * is installed. Note that the returned revision is the revision of the > + * Trusted OS, not of the API. > + * > + * Returns revision in a0-1 in the same way as OPTEE_SMC_CALLS_REVISION > + * described above. > + */ > +#define OPTEE_SMC_FUNCID_GET_OS_REVISION OPTEE_MSG_FUNCID_GET_OS_REVISION > +#define OPTEE_SMC_CALL_GET_OS_REVISION \ > + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_REVISION) > + > +/* > + * Call with struct optee_msg_arg as argument > + * > + * Call register usage: > + * a0 SMC Function ID, OPTEE_SMC*CALL_WITH_ARG > + * a1 Upper 32bit of a 64bit physical pointer to a struct optee_msg_arg > + * a2 Lower 32bit of a 64bit physical pointer to a struct optee_msg_arg > + * a3 Cache settings, not used if physical pointer is in a predefined shared > + * memory area else per OPTEE_SMC_SHM_* > + * a4-6 Not used > + * a7 Hypervisor Client ID register > + * > + * Normal return register usage: > + * a0 Return value, OPTEE_SMC_RETURN_* > + * a1-3 Not used > + * a4-7 Preserved > + * > + * OPTEE_SMC_RETURN_ETHREAD_LIMIT return register usage: > + * a0 Return value, OPTEE_SMC_RETURN_ETHREAD_LIMIT > + * a1-3 Preserved > + * a4-7 Preserved > + * > + * RPC return register usage: > + * a0 Return value, OPTEE_SMC_RETURN_IS_RPC(val) > + * a1-2 RPC parameters > + * a3-7 Resume information, must be preserved > + * > + * Possible return values: > + * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION Trusted OS does not recognize this > + * function. > + * OPTEE_SMC_RETURN_OK Call completed, result updated in > + * the previously supplied struct > + * optee_msg_arg. > + * OPTEE_SMC_RETURN_ETHREAD_LIMIT Number of Trusted OS threads exceeded, > + * try again later. > + * OPTEE_SMC_RETURN_EBADADDR Bad physcial pointer to struct > + * optee_msg_arg. > + * OPTEE_SMC_RETURN_EBADCMD Bad/unknown cmd in struct optee_msg_arg > + * OPTEE_SMC_RETURN_IS_RPC() Call suspended by RPC call to normal > + * world. > + */ > +#define OPTEE_SMC_FUNCID_CALL_WITH_ARG OPTEE_MSG_FUNCID_CALL_WITH_ARG > +#define OPTEE_SMC_CALL_WITH_ARG \ > + OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_CALL_WITH_ARG) > + > +/* > + * Get Shared Memory Config > + * > + * Returns the Secure/Non-secure shared memory config. > + * > + * Call register usage: > + * a0 SMC Function ID, OPTEE_SMC_GET_SHM_CONFIG > + * a1-6 Not used > + * a7 Hypervisor Client ID register > + * > + * Have config return register usage: > + * a0 OPTEE_SMC_RETURN_OK > + * a1 Physical address of start of SHM > + * a2 Size of of SHM > + * a3 Cache settings of memory, as defined by the > + * OPTEE_SMC_SHM_* values above > + * a4-7 Preserved > + * > + * Not available register usage: > + * a0 OPTEE_SMC_RETURN_ENOTAVAIL > + * a1-3 Not used > + * a4-7 Preserved > + */ > +#define OPTEE_SMC_FUNCID_GET_SHM_CONFIG 7 > +#define OPTEE_SMC_GET_SHM_CONFIG \ > + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_SHM_CONFIG) > + > +struct optee_smc_get_shm_config_result { > + unsigned long status; > + unsigned long start; > + unsigned long size; > + unsigned long settings; > +}; > + > +/* > + * Exchanges capabilities between normal world and secure world > + * > + * Call register usage: > + * a0 SMC Function ID, OPTEE_SMC_EXCHANGE_CAPABILITIES > + * a1 bitfield of normal world capabilities OPTEE_SMC_NSEC_CAP_* > + * a2-6 Not used > + * a7 Hypervisor Client ID register > + * > + * Normal return register usage: > + * a0 OPTEE_SMC_RETURN_OK > + * a1 bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_* > + * a2-7 Preserved > + * > + * Error return register usage: > + * a0 OPTEE_SMC_RETURN_ENOTAVAIL, can't use the capabilities from normal world > + * a1 bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_* > + * a2-7 Preserved > + */ > +/* Normal world works as a uniprocessor system */ > +#define OPTEE_SMC_NSEC_CAP_UNIPROCESSOR BIT(0) > +/* Secure world has reserved shared memory for normal world to use */ > +#define OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM BIT(0) > +/* Secure world can communicate via previously unregistered shared memory */ > +#define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM BIT(1) > + > +/* > + * Secure world supports commands "register/unregister shared memory", > + * secure world accepts command buffers located in any parts of non-secure RAM > + */ > +#define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM BIT(2) > + > +#define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9 > +#define OPTEE_SMC_EXCHANGE_CAPABILITIES \ > + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES) > + > +struct optee_smc_exchange_capabilities_result { > + unsigned long status; > + unsigned long capabilities; > + unsigned long reserved0; > + unsigned long reserved1; > +}; > + > +/* > + * Disable and empties cache of shared memory objects > + * > + * Secure world can cache frequently used shared memory objects, for > + * example objects used as RPC arguments. When secure world is idle this > + * function returns one shared memory reference to free. To disable the > + * cache and free all cached objects this function has to be called until > + * it returns OPTEE_SMC_RETURN_ENOTAVAIL. > + * > + * Call register usage: > + * a0 SMC Function ID, OPTEE_SMC_DISABLE_SHM_CACHE > + * a1-6 Not used > + * a7 Hypervisor Client ID register > + * > + * Normal return register usage: > + * a0 OPTEE_SMC_RETURN_OK > + * a1 Upper 32bit of a 64bit Shared memory cookie > + * a2 Lower 32bit of a 64bit Shared memory cookie > + * a3-7 Preserved > + * > + * Cache empty return register usage: > + * a0 OPTEE_SMC_RETURN_ENOTAVAIL > + * a1-7 Preserved > + * > + * Not idle return register usage: > + * a0 OPTEE_SMC_RETURN_EBUSY > + * a1-7 Preserved > + */ > +#define OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE 10 > +#define OPTEE_SMC_DISABLE_SHM_CACHE \ > + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE) > + > +struct optee_smc_disable_shm_cache_result { > + unsigned long status; > + unsigned long shm_upper32; > + unsigned long shm_lower32; > + unsigned long reserved0; > +}; > + > +/* > + * Enable cache of shared memory objects > + * > + * Secure world can cache frequently used shared memory objects, for > + * example objects used as RPC arguments. When secure world is idle this > + * function returns OPTEE_SMC_RETURN_OK and the cache is enabled. If > + * secure world isn't idle OPTEE_SMC_RETURN_EBUSY is returned. > + * > + * Call register usage: > + * a0 SMC Function ID, OPTEE_SMC_ENABLE_SHM_CACHE > + * a1-6 Not used > + * a7 Hypervisor Client ID register > + * > + * Normal return register usage: > + * a0 OPTEE_SMC_RETURN_OK > + * a1-7 Preserved > + * > + * Not idle return register usage: > + * a0 OPTEE_SMC_RETURN_EBUSY > + * a1-7 Preserved > + */ > +#define OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE 11 > +#define OPTEE_SMC_ENABLE_SHM_CACHE \ > + OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE) > + > +/* > + * Resume from RPC (for example after processing a foreign interrupt) > + * > + * Call register usage: > + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC > + * a1-3 Value of a1-3 when OPTEE_SMC_CALL_WITH_ARG returned > + * OPTEE_SMC_RETURN_RPC in a0 > + * > + * Return register usage is the same as for OPTEE_SMC_*CALL_WITH_ARG above. > + * > + * Possible return values > + * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION Trusted OS does not recognize this > + * function. > + * OPTEE_SMC_RETURN_OK Original call completed, result > + * updated in the previously supplied. > + * struct optee_msg_arg > + * OPTEE_SMC_RETURN_RPC Call suspended by RPC call to normal > + * world. > + * OPTEE_SMC_RETURN_ERESUME Resume failed, the opaque resume > + * information was corrupt. > + */ > +#define OPTEE_SMC_FUNCID_RETURN_FROM_RPC 3 > +#define OPTEE_SMC_CALL_RETURN_FROM_RPC \ > + OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_RETURN_FROM_RPC) > + > +#define OPTEE_SMC_RETURN_RPC_PREFIX_MASK 0xFFFF0000 > +#define OPTEE_SMC_RETURN_RPC_PREFIX 0xFFFF0000 > +#define OPTEE_SMC_RETURN_RPC_FUNC_MASK 0x0000FFFF > + > +#define OPTEE_SMC_RETURN_GET_RPC_FUNC(ret) \ > + ((ret) & OPTEE_SMC_RETURN_RPC_FUNC_MASK) > + > +#define OPTEE_SMC_RPC_VAL(func) ((func) | OPTEE_SMC_RETURN_RPC_PREFIX) > + > +/* > + * Allocate memory for RPC parameter passing. The memory is used to hold a > + * struct optee_msg_arg. > + * > + * "Call" register usage: > + * a0 This value, OPTEE_SMC_RETURN_RPC_ALLOC > + * a1 Size in bytes of required argument memory > + * a2 Not used > + * a3 Resume information, must be preserved > + * a4-5 Not used > + * a6-7 Resume information, must be preserved > + * > + * "Return" register usage: > + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. > + * a1 Upper 32bits of 64bit physical pointer to allocated > + * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't > + * be allocated. > + * a2 Lower 32bits of 64bit physical pointer to allocated > + * memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't > + * be allocated > + * a3 Preserved > + * a4 Upper 32bits of 64bit Shared memory cookie used when freeing > + * the memory or doing an RPC > + * a5 Lower 32bits of 64bit Shared memory cookie used when freeing > + * the memory or doing an RPC > + * a6-7 Preserved > + */ > +#define OPTEE_SMC_RPC_FUNC_ALLOC 0 > +#define OPTEE_SMC_RETURN_RPC_ALLOC \ > + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_ALLOC) > + > +/* > + * Free memory previously allocated by OPTEE_SMC_RETURN_RPC_ALLOC > + * > + * "Call" register usage: > + * a0 This value, OPTEE_SMC_RETURN_RPC_FREE > + * a1 Upper 32bits of 64bit shared memory cookie belonging to this > + * argument memory > + * a2 Lower 32bits of 64bit shared memory cookie belonging to this > + * argument memory > + * a3-7 Resume information, must be preserved > + * > + * "Return" register usage: > + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. > + * a1-2 Not used > + * a3-7 Preserved > + */ > +#define OPTEE_SMC_RPC_FUNC_FREE 2 > +#define OPTEE_SMC_RETURN_RPC_FREE \ > + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FREE) > + > +/* > + * Deliver foreign interrupt to normal world. > + * > + * "Call" register usage: > + * a0 OPTEE_SMC_RETURN_RPC_FOREIGN_INTR > + * a1-7 Resume information, must be preserved > + * > + * "Return" register usage: > + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. > + * a1-7 Preserved > + */ > +#define OPTEE_SMC_RPC_FUNC_FOREIGN_INTR 4 > +#define OPTEE_SMC_RETURN_RPC_FOREIGN_INTR \ > + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FOREIGN_INTR) > + > +/* > + * Do an RPC request. The supplied struct optee_msg_arg tells which > + * request to do and the parameters for the request. The following fields > + * are used (the rest are unused): > + * - cmd the Request ID > + * - ret return value of the request, filled in by normal world > + * - num_params number of parameters for the request > + * - params the parameters > + * - param_attrs attributes of the parameters > + * > + * "Call" register usage: > + * a0 OPTEE_SMC_RETURN_RPC_CMD > + * a1 Upper 32bit of a 64bit Shared memory cookie holding a > + * struct optee_msg_arg, must be preserved, only the data should > + * be updated > + * a2 Lower 32bit of a 64bit Shared memory cookie holding a > + * struct optee_msg_arg, must be preserved, only the data should > + * be updated > + * a3-7 Resume information, must be preserved > + * > + * "Return" register usage: > + * a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC. > + * a1-2 Not used > + * a3-7 Preserved > + */ > +#define OPTEE_SMC_RPC_FUNC_CMD 5 > +#define OPTEE_SMC_RETURN_RPC_CMD \ > + OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_CMD) > + > +/* Returned in a0 */ > +#define OPTEE_SMC_RETURN_UNKNOWN_FUNCTION 0xFFFFFFFF > + > +/* Returned in a0 only from Trusted OS functions */ > +#define OPTEE_SMC_RETURN_OK 0x0 > +#define OPTEE_SMC_RETURN_ETHREAD_LIMIT 0x1 > +#define OPTEE_SMC_RETURN_EBUSY 0x2 > +#define OPTEE_SMC_RETURN_ERESUME 0x3 > +#define OPTEE_SMC_RETURN_EBADADDR 0x4 > +#define OPTEE_SMC_RETURN_EBADCMD 0x5 > +#define OPTEE_SMC_RETURN_ENOMEM 0x6 > +#define OPTEE_SMC_RETURN_ENOTAVAIL 0x7 > +#define OPTEE_SMC_RETURN_IS_RPC(ret) __optee_smc_return_is_rpc((ret)) > + > +static inline bool __optee_smc_return_is_rpc(u32 ret) > +{ > + return ret != OPTEE_SMC_RETURN_UNKNOWN_FUNCTION && > + (ret & OPTEE_SMC_RETURN_RPC_PREFIX_MASK) == > + OPTEE_SMC_RETURN_RPC_PREFIX; > +} > + > +#endif /* OPTEE_SMC_H */ > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 3/4] arm: tee: add OP-TEE header files 2017-10-16 14:04 ` Julien Grall @ 2017-10-17 16:24 ` Volodymyr Babchuk 2017-10-17 16:41 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-17 16:24 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, Stefano Stabellini, xen-devel On Mon, Oct 16, 2017 at 03:04:44PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, > On 11/10/17 20:01, Volodymyr Babchuk wrote: > >This header files describe protocol between OP-TEE and OP-TEE client > >driver in Linux. They are needed for upcomient OP-TEE mediator, which > >is added in the next patch. > >Reason to add those headers in separate patch is to ease up review. > >Those files were taken from linux tree (drivers/tee/optee/) and mangled > >a bit to compile with XEN. > > > >Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >--- > > xen/arch/arm/tee/optee_msg.h | 444 +++++++++++++++++++++++++++++++++++++++++ > > xen/arch/arm/tee/optee_smc.h | 457 +++++++++++++++++++++++++++++++++++++++++++ > > Headers should go in include/asm-arm/tee and not arch/arm. This headers are used only by optee.c in the same folder. Do I need to make them public? WBR, Volodymyr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 3/4] arm: tee: add OP-TEE header files 2017-10-17 16:24 ` Volodymyr Babchuk @ 2017-10-17 16:41 ` Julien Grall 0 siblings, 0 replies; 44+ messages in thread From: Julien Grall @ 2017-10-17 16:41 UTC (permalink / raw) To: Volodymyr Babchuk; +Cc: Julien Grall, Stefano Stabellini, xen-devel Hi, On 17/10/17 17:24, Volodymyr Babchuk wrote: > On Mon, Oct 16, 2017 at 03:04:44PM +0100, Julien Grall wrote: >> Hi Volodymyr, > Hi Julien, > >> On 11/10/17 20:01, Volodymyr Babchuk wrote: >>> This header files describe protocol between OP-TEE and OP-TEE client >>> driver in Linux. They are needed for upcomient OP-TEE mediator, which >>> is added in the next patch. >>> Reason to add those headers in separate patch is to ease up review. >>> Those files were taken from linux tree (drivers/tee/optee/) and mangled >>> a bit to compile with XEN. >>> >>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>> --- >>> xen/arch/arm/tee/optee_msg.h | 444 +++++++++++++++++++++++++++++++++++++++++ >>> xen/arch/arm/tee/optee_smc.h | 457 +++++++++++++++++++++++++++++++++++++++++++ >> >> Headers should go in include/asm-arm/tee and not arch/arm. > This headers are used only by optee.c in the same folder. Do I need to make > them public? They are not going to be public, just internal to Xen. But not in arch/arm, I know we did in some occasions but I would rather keep all the headers in include/asm-arm. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-11 19:01 [RFC 0/4] TEE mediator framework + OP-TEE mediator Volodymyr Babchuk ` (2 preceding siblings ...) 2017-10-11 19:01 ` [RFC 3/4] arm: tee: add OP-TEE header files Volodymyr Babchuk @ 2017-10-11 19:01 ` Volodymyr Babchuk 2017-10-16 14:36 ` Julien Grall 2017-10-16 12:00 ` [RFC 0/4] TEE mediator framework + " Julien Grall 4 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-11 19:01 UTC (permalink / raw) To: Stefano Stabellini, Julien Grall, xen-devel Cc: Volodymyr Babchuk, Jens Wiklander Add basic OP-TEE mediator as an example how TEE mediator framework works. Currently it support only calls from Dom0. Calls from other guests will be declined. It maps OP-TEE static shared memory region into Dom0 address space, so Dom0 is the only domain which can work with older versions of OP-TEE. Also it alters SMC requests by\ adding domain id to request. OP-TEE can use this information to track requesters. Albeit being in early development stages, this mediator already can be used on systems where only Dom0 interacts with OP-TEE. It was tested on RCAR Salvator-M3 board. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> --- xen/arch/arm/tee/Kconfig | 4 ++ xen/arch/arm/tee/Makefile | 1 + xen/arch/arm/tee/optee.c | 178 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 183 insertions(+) create mode 100644 xen/arch/arm/tee/optee.c diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig index e69de29..7c6b5c6 100644 --- a/xen/arch/arm/tee/Kconfig +++ b/xen/arch/arm/tee/Kconfig @@ -0,0 +1,4 @@ +config ARM_OPTEE + bool "Enable OP-TEE mediator" + default n + depends on ARM_TEE diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile index c54d479..9d93b42 100644 --- a/xen/arch/arm/tee/Makefile +++ b/xen/arch/arm/tee/Makefile @@ -1 +1,2 @@ obj-y += tee.o +obj-$(CONFIG_ARM_OPTEE) += optee.o diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c new file mode 100644 index 0000000..0220691 --- /dev/null +++ b/xen/arch/arm/tee/optee.c @@ -0,0 +1,178 @@ +/* + * xen/arch/arm/tee/optee.c + * + * OP-TEE mediator + * + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> + * Copyright (c) 2017 EPAM Systems. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <xen/types.h> +#include <xen/sched.h> + +#include <asm/p2m.h> +#include <asm/tee.h> + +#include "optee_msg.h" +#include "optee_smc.h" + +/* + * OP-TEE violates SMCCC when it defines own UID. So we need + * to place bytes in correct order. + */ +#define OPTEE_UID (xen_uuid_t){{ \ + (uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8), \ + (uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24), \ + (uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8), \ + (uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24), \ + (uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8), \ + (uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24), \ + (uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8), \ + (uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24), \ + }} + +static int optee_init(void) +{ + printk("OP-TEE mediator init done\n"); + return 0; +} + +static void optee_domain_create(struct domain *d) +{ + /* + * Do nothing at this time. + * In the future this function will notify that new VM is started. + */ +} + +static void optee_domain_destroy(struct domain *d) +{ + /* + * Do nothing at this time. + * In the future this function will notify that VM is being destroyed. + */ +} + +static bool forward_call(struct cpu_user_regs *regs) +{ + register_t resp[4]; + + call_smccc_smc(get_user_reg(regs, 0), + get_user_reg(regs, 1), + get_user_reg(regs, 2), + get_user_reg(regs, 3), + get_user_reg(regs, 4), + get_user_reg(regs, 5), + get_user_reg(regs, 6), + /* VM id 0 is reserved for hypervisor itself */ + current->domain->domain_id +1, + resp); + + set_user_reg(regs, 0, resp[0]); + set_user_reg(regs, 1, resp[1]); + set_user_reg(regs, 2, resp[2]); + set_user_reg(regs, 3, resp[3]); + + return true; +} + +static bool handle_get_shm_config(struct cpu_user_regs *regs) +{ + paddr_t shm_start; + size_t shm_size; + int rc; + + printk("handle_get_shm_config\n"); + /* Give all static SHM region to the Dom0 */ + if ( current->domain->domain_id != 0 ) + return false; + + forward_call(regs); + + /* Return error back to the guest */ + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) + return true; + + shm_start = get_user_reg(regs, 1); + shm_size = get_user_reg(regs, 2); + + /* Dom0 is mapped 1:1 */ + rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), + shm_size / PAGE_SIZE, + maddr_to_mfn(shm_start), + p2m_ram_rw); + if ( rc < 0 ) + { + gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); + } + + return true; +} + +static bool handle_exchange_capabilities(struct cpu_user_regs *regs) +{ + forward_call(regs); + + printk("handle_exchange_capabilities\n"); + /* Return error back to the guest */ + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) + return true; + + /* Don't allow guests to work without dynamic SHM */ + if (current->domain->domain_id != 0 && + !(get_user_reg(regs, 1) & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) ) + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); + return true; +} + +static bool optee_handle_smc(struct cpu_user_regs *regs) +{ + /* At this time we support only calls from Dom0. */ + if ( current->domain->domain_id != 0 ) + return false; + + switch ( get_user_reg(regs, 0) ) + { + case OPTEE_SMC_GET_SHM_CONFIG: + return handle_get_shm_config(regs); + case OPTEE_SMC_EXCHANGE_CAPABILITIES: + return handle_exchange_capabilities(regs); + default: + return forward_call(regs); + } + return true; +} + +static void optee_remove(void) +{ +} + +static const struct tee_mediator_ops optee_ops = +{ + .init = optee_init, + .domain_create = optee_domain_create, + .domain_destroy = optee_domain_destroy, + .handle_smc = optee_handle_smc, + .remove = optee_remove, +}; + +REGISTER_TEE_MEDIATOR(optee, "OP-TEE", OPTEE_UID, &optee_ops); + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.7.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-11 19:01 ` [RFC 4/4] arm: tee: add basic OP-TEE mediator Volodymyr Babchuk @ 2017-10-16 14:36 ` Julien Grall 2017-10-17 17:08 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-16 14:36 UTC (permalink / raw) To: Volodymyr Babchuk, Stefano Stabellini, Julien Grall, xen-devel Cc: Jens Wiklander Hi Volodymyr, On 11/10/17 20:01, Volodymyr Babchuk wrote: > Add basic OP-TEE mediator as an example how TEE mediator framework > works. > > Currently it support only calls from Dom0. Calls from other guests > will be declined. It maps OP-TEE static shared memory region into > Dom0 address space, so Dom0 is the only domain which can work with > older versions of OP-TEE. > > Also it alters SMC requests by\ adding domain id to request. OP-TEE > can use this information to track requesters. > > Albeit being in early development stages, this mediator already can > be used on systems where only Dom0 interacts with OP-TEE. A link to the spec would be useful here to be able to fully review this patch. > > It was tested on RCAR Salvator-M3 board. Is it with the stock op-tee? Or an updated version? > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > xen/arch/arm/tee/Kconfig | 4 ++ > xen/arch/arm/tee/Makefile | 1 + > xen/arch/arm/tee/optee.c | 178 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 183 insertions(+) > create mode 100644 xen/arch/arm/tee/optee.c > > diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig > index e69de29..7c6b5c6 100644 > --- a/xen/arch/arm/tee/Kconfig > +++ b/xen/arch/arm/tee/Kconfig > @@ -0,0 +1,4 @@ > +config ARM_OPTEE > + bool "Enable OP-TEE mediator" > + default n > + depends on ARM_TEE > diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile > index c54d479..9d93b42 100644 > --- a/xen/arch/arm/tee/Makefile > +++ b/xen/arch/arm/tee/Makefile > @@ -1 +1,2 @@ > obj-y += tee.o > +obj-$(CONFIG_ARM_OPTEE) += optee.o > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > new file mode 100644 > index 0000000..0220691 > --- /dev/null > +++ b/xen/arch/arm/tee/optee.c > @@ -0,0 +1,178 @@ > +/* > + * xen/arch/arm/tee/optee.c > + * > + * OP-TEE mediator > + * > + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> > + * Copyright (c) 2017 EPAM Systems. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <xen/types.h> > +#include <xen/sched.h> > + > +#include <asm/p2m.h> > +#include <asm/tee.h> > + > +#include "optee_msg.h" > +#include "optee_smc.h" > + > +/* > + * OP-TEE violates SMCCC when it defines own UID. So we need > + * to place bytes in correct order. Can you please point the paragraph in the spec where it says that? > + */ > +#define OPTEE_UID (xen_uuid_t){{ \ > + (uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8), \ > + (uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24), \ > + (uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8), \ > + (uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24), \ > + (uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8), \ > + (uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24), \ > + (uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8), \ > + (uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24), \ > + }} > + > +static int optee_init(void) > +{ > + printk("OP-TEE mediator init done\n"); > + return 0; > +} > + > +static void optee_domain_create(struct domain *d) > +{ > + /* > + * Do nothing at this time. > + * In the future this function will notify that new VM is started. You already have a new client with the hardware domain. So don't you already need to notifity OP-TEE? > + */ > +} > + > +static void optee_domain_destroy(struct domain *d) > +{ > + /* > + * Do nothing at this time. > + * In the future this function will notify that VM is being destroyed. > + */ Same for the destruction? > +} > + > +static bool forward_call(struct cpu_user_regs *regs) > +{ > + register_t resp[4]; > + > + call_smccc_smc(get_user_reg(regs, 0), > + get_user_reg(regs, 1), > + get_user_reg(regs, 2), > + get_user_reg(regs, 3), > + get_user_reg(regs, 4), > + get_user_reg(regs, 5), > + get_user_reg(regs, 6), > + /* VM id 0 is reserved for hypervisor itself */ s/VM/client/. Also, on your design document you mentioned that you did modify OP-TEE to support multiple client ID. So how do you know whether the TEE supports client ID? Similarly, do you expect OP-TEE to support 16-bit of client identifier? > + current->domain->domain_id +1, > + resp); > + > + set_user_reg(regs, 0, resp[0]); > + set_user_reg(regs, 1, resp[1]); > + set_user_reg(regs, 2, resp[2]); > + set_user_reg(regs, 3, resp[3]); Who will do the sanity check of the return values? Each callers? If so, I would prefer that the results are stored in a temporary array and a separate helpers will write them into the domain once the sanity is done. This would avoid to mistakenly expose unwanted data to a domain. > + > + return true; > +} > + > +static bool handle_get_shm_config(struct cpu_user_regs *regs) > +{ > + paddr_t shm_start; > + size_t shm_size; > + int rc; > + > + printk("handle_get_shm_config\n"); No plain printk in code accessible by the guest. You should use gprintk or ratelimit it. > + /* Give all static SHM region to the Dom0 */ s/Dom0/Hardware Domain/ But I am not sure what's the point of this check given OP-TEE is only supported for the Hardware Domain and you already have a check for that. > + if ( current->domain->domain_id != 0 ) Please use is_hardware_domain(current->domain) and not open-code the check. > + return false; > + > + forward_call(regs); > + > + /* Return error back to the guest */ > + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) > + return true; This is quite confusing to read, I think it would make sense that forward_call return the error. > + > + shm_start = get_user_reg(regs, 1); > + shm_size = get_user_reg(regs, 2); > + > + /* Dom0 is mapped 1:1 */ Please don't make this assumption or at least add ASSERT(is_domain_direct_mapped(d)); > + rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), Rather than using current->domain everywhere, I would prefer if you introduce a temporary variable for the domain. > + shm_size / PAGE_SIZE, Please PFN_DOWN(...). > + maddr_to_mfn(shm_start), > + p2m_ram_rw); What is this shared memory for? I know this is the hardware domain, so using p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do proper safety check. > + if ( rc < 0 ) > + { > + gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); gprintk already dump the domid. So no need to say Dom0. > + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); > + } > + > + return true; > +} > + > +static bool handle_exchange_capabilities(struct cpu_user_regs *regs) > +{ > + forward_call(regs); > + > + printk("handle_exchange_capabilities\n"); Same here, no plain prink. > + /* Return error back to the guest */ > + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) > + return true; > + > + /* Don't allow guests to work without dynamic SHM */ Hmmm? But you don't support guests today. So why are you checking that? I would prefer if you either support guest or not. But not half of it as it is hard to know how this will end up. > + if (current->domain->domain_id != 0 && > + !(get_user_reg(regs, 1) & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) ) > + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); Missing newline. > + return true; > +} > + > +static bool optee_handle_smc(struct cpu_user_regs *regs) > +{ > + /* At this time we support only calls from Dom0. */ > + if ( current->domain->domain_id != 0 ) is_hardware_domain(d) > + return false; > + > + switch ( get_user_reg(regs, 0) ) > + { > + case OPTEE_SMC_GET_SHM_CONFIG: > + return handle_get_shm_config(regs); > + case OPTEE_SMC_EXCHANGE_CAPABILITIES: > + return handle_exchange_capabilities(regs); > + default: > + return forward_call(regs); > + } > + return true; The return here is not necessary. > +} > + > +static void optee_remove(void) > +{ > +} > + > +static const struct tee_mediator_ops optee_ops = > +{ > + .init = optee_init, > + .domain_create = optee_domain_create, > + .domain_destroy = optee_domain_destroy, > + .handle_smc = optee_handle_smc, > + .remove = optee_remove, > +}; > + > +REGISTER_TEE_MEDIATOR(optee, "OP-TEE", OPTEE_UID, &optee_ops); > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-16 14:36 ` Julien Grall @ 2017-10-17 17:08 ` Volodymyr Babchuk 2017-10-17 17:30 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-17 17:08 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel On Mon, Oct 16, 2017 at 03:36:38PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, > On 11/10/17 20:01, Volodymyr Babchuk wrote: > >Add basic OP-TEE mediator as an example how TEE mediator framework > >works. > > > >Currently it support only calls from Dom0. Calls from other guests > >will be declined. It maps OP-TEE static shared memory region into > >Dom0 address space, so Dom0 is the only domain which can work with > >older versions of OP-TEE. > > > >Also it alters SMC requests by\ adding domain id to request. OP-TEE > >can use this information to track requesters. > > > >Albeit being in early development stages, this mediator already can > >be used on systems where only Dom0 interacts with OP-TEE. > > A link to the spec would be useful here to be able to fully review this > patch. Which spec? OP-TEE protocol? It was added in previous commit. > > > >It was tested on RCAR Salvator-M3 board. > > Is it with the stock op-tee? Or an updated version? Static SHM was tested with stock OP-TEE. Dynamic SHM was tested with my build. But my patches are already merged. OP-TEE 2.6.0 will support dynamic SHM out of the box. > > > >Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >--- > > xen/arch/arm/tee/Kconfig | 4 ++ > > xen/arch/arm/tee/Makefile | 1 + > > xen/arch/arm/tee/optee.c | 178 ++++++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 183 insertions(+) > > create mode 100644 xen/arch/arm/tee/optee.c > > > >diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig > >index e69de29..7c6b5c6 100644 > >--- a/xen/arch/arm/tee/Kconfig > >+++ b/xen/arch/arm/tee/Kconfig > >@@ -0,0 +1,4 @@ > >+config ARM_OPTEE > >+ bool "Enable OP-TEE mediator" > >+ default n > >+ depends on ARM_TEE > >diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile > >index c54d479..9d93b42 100644 > >--- a/xen/arch/arm/tee/Makefile > >+++ b/xen/arch/arm/tee/Makefile > >@@ -1 +1,2 @@ > > obj-y += tee.o > >+obj-$(CONFIG_ARM_OPTEE) += optee.o > >diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > >new file mode 100644 > >index 0000000..0220691 > >--- /dev/null > >+++ b/xen/arch/arm/tee/optee.c > >@@ -0,0 +1,178 @@ > >+/* > >+ * xen/arch/arm/tee/optee.c > >+ * > >+ * OP-TEE mediator > >+ * > >+ * Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >+ * Copyright (c) 2017 EPAM Systems. > >+ * > >+ * This program is free software; you can redistribute it and/or modify > >+ * it under the terms of the GNU General Public License version 2 as > >+ * published by the Free Software Foundation. > >+ * > >+ * This program is distributed in the hope that it will be useful, > >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of > >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >+ * GNU General Public License for more details. > >+ */ > >+ > >+#include <xen/types.h> > >+#include <xen/sched.h> > >+ > >+#include <asm/p2m.h> > >+#include <asm/tee.h> > >+ > >+#include "optee_msg.h" > >+#include "optee_smc.h" > >+ > >+/* > >+ * OP-TEE violates SMCCC when it defines own UID. So we need > >+ * to place bytes in correct order. > > Can you please point the paragraph in the spec where it says that? Sure. > >+ */ > >+#define OPTEE_UID (xen_uuid_t){{ \ > >+ (uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8), \ > >+ (uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24), \ > >+ (uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8), \ > >+ (uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24), \ > >+ (uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8), \ > >+ (uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24), \ > >+ (uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8), \ > >+ (uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24), \ > >+ }} > >+ > >+static int optee_init(void) > >+{ > >+ printk("OP-TEE mediator init done\n"); > >+ return 0; > >+} > >+ > >+static void optee_domain_create(struct domain *d) > >+{ > >+ /* > >+ * Do nothing at this time. > >+ * In the future this function will notify that new VM is started. > > You already have a new client with the hardware domain. So don't you already > need to notifity OP-TEE? Because currently OP-TEE does not support such notification. > >+ */ > >+} > >+ > >+static void optee_domain_destroy(struct domain *d) > >+{ > >+ /* > >+ * Do nothing at this time. > >+ * In the future this function will notify that VM is being destroyed. > >+ */ > > Same for the destruction? The same answer. OP-TEE currently can work with only one domain. I selected Dom0 for this. > >+} > >+ > >+static bool forward_call(struct cpu_user_regs *regs) > >+{ > >+ register_t resp[4]; > >+ > >+ call_smccc_smc(get_user_reg(regs, 0), > >+ get_user_reg(regs, 1), > >+ get_user_reg(regs, 2), > >+ get_user_reg(regs, 3), > >+ get_user_reg(regs, 4), > >+ get_user_reg(regs, 5), > >+ get_user_reg(regs, 6), > >+ /* VM id 0 is reserved for hypervisor itself */ > > s/VM/client/. Also, on your design document you mentioned that you did > modify OP-TEE to support multiple client ID. So how do you know whether the > TEE supports client ID? Hm, as I remember, I never mentioned that I modified OP-TEE to support multiple client IDs. This is my current task. But, answering your question, optee_domain_create() will tell OP-TEE about new client ID. > Similarly, do you expect OP-TEE to support 16-bit of client identifier? Actually, yes. But I don't expect it to work with all 65535 domains at the same time. > >+ current->domain->domain_id +1, > >+ resp); > >+ > >+ set_user_reg(regs, 0, resp[0]); > >+ set_user_reg(regs, 1, resp[1]); > >+ set_user_reg(regs, 2, resp[2]); > >+ set_user_reg(regs, 3, resp[3]); > > Who will do the sanity check of the return values? Each callers? If so, I > would prefer that the results are stored in a temporary array and a separate > helpers will write them into the domain once the sanity is done. Maybe there will be cases when call will be forwarded straight to OP-TEE and nobody in hypervisor will examine returned result. At least, at this moment there are such cases. Probably, in full-scalle mediator this will no longer be true. > This would avoid to mistakenly expose unwanted data to a domain. Correct me, but set_user_reg() modifies data that will be stored in general purpose registers during return from trap handler. This can't expose any additional data to a domain. > >+ > >+ return true; > >+} > >+ > >+static bool handle_get_shm_config(struct cpu_user_regs *regs) > >+{ > >+ paddr_t shm_start; > >+ size_t shm_size; > >+ int rc; > >+ > >+ printk("handle_get_shm_config\n"); > > No plain printk in code accessible by the guest. You should use gprintk or > ratelimit it. Sorry, this is a debug print. I'll remove it at all. > >+ /* Give all static SHM region to the Dom0 */ > > s/Dom0/Hardware Domain/ Hm, looks like Dom0 != hardware domain. At least I see code that replaces contents of hardware_domain variable. If it is possible, then there will be a problem with static SHM buffer. Looks like it is better to check for is_domain_direct_mapped(d), as you mentioned below. > But I am not sure what's the point of this check given OP-TEE is only > supported for the Hardware Domain and you already have a check for that. Because I will remove outer check. But this check will remain. In this way older OP-TEEs (without virtualization support) will still be accessible from Dom0/HWDom. > >+ if ( current->domain->domain_id != 0 ) > > Please use is_hardware_domain(current->domain) and not open-code the check. > > >+ return false; > >+ > >+ forward_call(regs); > >+ > >+ /* Return error back to the guest */ > >+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) > >+ return true; > > This is quite confusing to read, I think it would make sense that > forward_call return the error. Good idea, thanks. > >+ > >+ shm_start = get_user_reg(regs, 1); > >+ shm_size = get_user_reg(regs, 2); > >+ > >+ /* Dom0 is mapped 1:1 */ > > Please don't make this assumption or at least add > ASSERT(is_domain_direct_mapped(d)); Thanks. I'll check this in runtime, as I mentioned above. > >+ rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), > > Rather than using current->domain everywhere, I would prefer if you > introduce a temporary variable for the domain. Okay. > >+ shm_size / PAGE_SIZE, > > Please PFN_DOWN(...). > > >+ maddr_to_mfn(shm_start), > >+ p2m_ram_rw); > > What is this shared memory for? I know this is the hardware domain, so using > p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do > proper safety check. Linux kernel driver does memremap() in such place. OP-TEE maps it as non-secure RAM. This shared memory is used to pass information between OP-TEE OS and OP-TEE client. About which safety check you are talking? > > >+ if ( rc < 0 ) > >+ { > >+ gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); > > gprintk already dump the domid. So no need to say Dom0. I just wanted to emphasis that we mappaed memory for Dom0. Will remove. > >+ set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); > >+ } > >+ > >+ return true; > >+} > >+ > >+static bool handle_exchange_capabilities(struct cpu_user_regs *regs) > >+{ > >+ forward_call(regs); > >+ > >+ printk("handle_exchange_capabilities\n"); > > Same here, no plain prink. Sorry, this is another debug print. Missed it when formatted patches. > >+ /* Return error back to the guest */ > >+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) > >+ return true; > >+ > >+ /* Don't allow guests to work without dynamic SHM */ > > Hmmm? But you don't support guests today. So why are you checking that? This is a RFC. Will remove this parts of the code in a proper patch series. I just wanted to ensure that community is okay with proposed approach and to show how minimalistic mediator can look. If you are generally okay with that, I'll address all comments, rework second patch and push proper patch series. WBR, Volodymyr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-17 17:08 ` Volodymyr Babchuk @ 2017-10-17 17:30 ` Julien Grall 2017-10-17 18:57 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-17 17:30 UTC (permalink / raw) To: Volodymyr Babchuk Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel On 17/10/17 18:08, Volodymyr Babchuk wrote: > On Mon, Oct 16, 2017 at 03:36:38PM +0100, Julien Grall wrote: >> Hi Volodymyr, > Hi Julien, > >> On 11/10/17 20:01, Volodymyr Babchuk wrote: >>> Add basic OP-TEE mediator as an example how TEE mediator framework >>> works. >>> >>> Currently it support only calls from Dom0. Calls from other guests >>> will be declined. It maps OP-TEE static shared memory region into >>> Dom0 address space, so Dom0 is the only domain which can work with >>> older versions of OP-TEE. >>> >>> Also it alters SMC requests by\ adding domain id to request. OP-TEE >>> can use this information to track requesters. >>> >>> Albeit being in early development stages, this mediator already can >>> be used on systems where only Dom0 interacts with OP-TEE. >> >> A link to the spec would be useful here to be able to fully review this >> patch. > Which spec? OP-TEE protocol? It was added in previous commit. So basically you are saying the header is the documentation of the API? There are not external documentation making easier to follow the version...? > >>> >>> It was tested on RCAR Salvator-M3 board. >> >> Is it with the stock op-tee? Or an updated version? > Static SHM was tested with stock OP-TEE. Dynamic SHM was tested with > my build. But my patches are already merged. OP-TEE 2.6.0 will support > dynamic SHM out of the box. > >>> >>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>> --- >>> xen/arch/arm/tee/Kconfig | 4 ++ >>> xen/arch/arm/tee/Makefile | 1 + >>> xen/arch/arm/tee/optee.c | 178 ++++++++++++++++++++++++++++++++++++++++++++++ >>> 3 files changed, 183 insertions(+) >>> create mode 100644 xen/arch/arm/tee/optee.c >>> >>> diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig >>> index e69de29..7c6b5c6 100644 >>> --- a/xen/arch/arm/tee/Kconfig >>> +++ b/xen/arch/arm/tee/Kconfig >>> @@ -0,0 +1,4 @@ >>> +config ARM_OPTEE >>> + bool "Enable OP-TEE mediator" >>> + default n >>> + depends on ARM_TEE >>> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile >>> index c54d479..9d93b42 100644 >>> --- a/xen/arch/arm/tee/Makefile >>> +++ b/xen/arch/arm/tee/Makefile >>> @@ -1 +1,2 @@ >>> obj-y += tee.o >>> +obj-$(CONFIG_ARM_OPTEE) += optee.o >>> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c >>> new file mode 100644 >>> index 0000000..0220691 >>> --- /dev/null >>> +++ b/xen/arch/arm/tee/optee.c >>> @@ -0,0 +1,178 @@ >>> +/* >>> + * xen/arch/arm/tee/optee.c >>> + * >>> + * OP-TEE mediator >>> + * >>> + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>> + * Copyright (c) 2017 EPAM Systems. >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License version 2 as >>> + * published by the Free Software Foundation. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + */ >>> + >>> +#include <xen/types.h> >>> +#include <xen/sched.h> >>> + >>> +#include <asm/p2m.h> >>> +#include <asm/tee.h> >>> + >>> +#include "optee_msg.h" >>> +#include "optee_smc.h" >>> + >>> +/* >>> + * OP-TEE violates SMCCC when it defines own UID. So we need >>> + * to place bytes in correct order. >> >> Can you please point the paragraph in the spec where it says that? > Sure. > >>> + */ >>> +#define OPTEE_UID (xen_uuid_t){{ \ >>> + (uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8), \ >>> + (uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24), \ >>> + (uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8), \ >>> + (uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24), \ >>> + (uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8), \ >>> + (uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24), \ >>> + (uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8), \ >>> + (uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24), \ >>> + }} >>> + >>> +static int optee_init(void) >>> +{ >>> + printk("OP-TEE mediator init done\n"); >>> + return 0; >>> +} >>> + >>> +static void optee_domain_create(struct domain *d) >>> +{ >>> + /* >>> + * Do nothing at this time. >>> + * In the future this function will notify that new VM is started. >> >> You already have a new client with the hardware domain. So don't you already >> need to notifity OP-TEE? > Because currently OP-TEE does not support such notification. > >>> + */ >>> +} >>> + >>> +static void optee_domain_destroy(struct domain *d) >>> +{ >>> + /* >>> + * Do nothing at this time. >>> + * In the future this function will notify that VM is being destroyed. >>> + */ >> >> Same for the destruction? > The same answer. OP-TEE currently can work with only one domain. I selected > Dom0 for this. > >>> +} >>> + >>> +static bool forward_call(struct cpu_user_regs *regs) >>> +{ >>> + register_t resp[4]; >>> + >>> + call_smccc_smc(get_user_reg(regs, 0), >>> + get_user_reg(regs, 1), >>> + get_user_reg(regs, 2), >>> + get_user_reg(regs, 3), >>> + get_user_reg(regs, 4), >>> + get_user_reg(regs, 5), >>> + get_user_reg(regs, 6), >>> + /* VM id 0 is reserved for hypervisor itself */ >> >> s/VM/client/. Also, on your design document you mentioned that you did >> modify OP-TEE to support multiple client ID. So how do you know whether the >> TEE supports client ID? > Hm, as I remember, I never mentioned that I modified OP-TEE to support > multiple client IDs. This is my current task. "On OP-TEE side: 1. Shared memory redesign which is almost complete. 2. Implement new SMCs from hypervsiror to TEE to track VM lifecycle. 3. Track VM IDs to isolated VM data. 4. RPCs to sleeping guests." I was kind of expecting that was done given you put a client ID here. If it is not done, then why are you passing a ID that we are not even sure OP-TEE will be able to understand? > But, answering your question, optee_domain_create() will tell OP-TEE about > new client ID. And I guess you would expect that the registration may fail, hence an error return is mandatory in optee_domain_create. > >> Similarly, do you expect OP-TEE to support 16-bit of client identifier? > Actually, yes. But I don't expect it to work with all 65535 domains at the > same time. So how many client do you expect to be supported? And how do you expect to get that information back? > >>> + current->domain->domain_id +1, >>> + resp); >>> + >>> + set_user_reg(regs, 0, resp[0]); >>> + set_user_reg(regs, 1, resp[1]); >>> + set_user_reg(regs, 2, resp[2]); >>> + set_user_reg(regs, 3, resp[3]); >> >> Who will do the sanity check of the return values? Each callers? If so, I >> would prefer that the results are stored in a temporary array and a separate >> helpers will write them into the domain once the sanity is done. > Maybe there will be cases when call will be forwarded straight to OP-TEE and > nobody in hypervisor will examine returned result. At least, at this moment > there are such cases. Probably, in full-scalle mediator this will no longer > be true. > >> This would avoid to mistakenly expose unwanted data to a domain. > Correct me, but set_user_reg() modifies data that will be stored in general > purpose registers during return from trap handler. This can't expose any > additional data to a domain. Which set_user_reg()? The helper does not do any modification... If you speak about the code below, then it is very confusing and error-prone. If you separate the call from setting the guest registers then the you give a hint to the caller that maybe something has to be down and he can't blindly trust the result... > >>> + >>> + return true; >>> +} >>> + >>> +static bool handle_get_shm_config(struct cpu_user_regs *regs) >>> +{ >>> + paddr_t shm_start; >>> + size_t shm_size; >>> + int rc; >>> + >>> + printk("handle_get_shm_config\n"); >> >> No plain printk in code accessible by the guest. You should use gprintk or >> ratelimit it. > Sorry, this is a debug print. I'll remove it at all. > >>> + /* Give all static SHM region to the Dom0 */ >> >> s/Dom0/Hardware Domain/ > Hm, looks like Dom0 != hardware domain. At least I see code that replaces > contents of hardware_domain variable. If it is possible, then there will > be a problem with static SHM buffer. On Arm Dom0 == Hardware Domain. If Hardware Domain were introduced, then I would expect OP-TEE to be handled by the it and not Dom0. > > Looks like it is better to check for is_domain_direct_mapped(d), as you > mentioned below. is_domain_direct_mapped(d) != hwdom. Please don't mix the both. The former is here to proctect you gfn == mfn. The latter is here to make sure no other domain than the hardware domain is going to use the shared memory. > >> But I am not sure what's the point of this check given OP-TEE is only >> supported for the Hardware Domain and you already have a check for that. > Because I will remove outer check. But this check will remain. In this way > older OP-TEEs (without virtualization support) will still be accessible > from Dom0/HWDom. > >>> + if ( current->domain->domain_id != 0 ) >> >> Please use is_hardware_domain(current->domain) and not open-code the check. >> >>> + return false; >>> + >>> + forward_call(regs); >>> + >>> + /* Return error back to the guest */ >>> + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>> + return true; >> >> This is quite confusing to read, I think it would make sense that >> forward_call return the error. > Good idea, thanks. > >>> + >>> + shm_start = get_user_reg(regs, 1); >>> + shm_size = get_user_reg(regs, 2); >>> + >>> + /* Dom0 is mapped 1:1 */ >> >> Please don't make this assumption or at least add >> ASSERT(is_domain_direct_mapped(d)); > Thanks. I'll check this in runtime, as I mentioned above. > >>> + rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), >> >> Rather than using current->domain everywhere, I would prefer if you >> introduce a temporary variable for the domain. > Okay. > >>> + shm_size / PAGE_SIZE, >> >> Please PFN_DOWN(...). >> >>> + maddr_to_mfn(shm_start), >>> + p2m_ram_rw); >> >> What is this shared memory for? I know this is the hardware domain, so using >> p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do >> proper safety check. > Linux kernel driver does memremap() in such place. OP-TEE maps it as non-secure > RAM. This shared memory is used to pass information between OP-TEE OS > and OP-TEE client. About which safety check you are talking? Well, does OP-TEE validate the data read from that shared region? But it seems that you don't plan to give part of the SHM to a guest, so it might be ok. Also how OP-TEE will map this region? Cacheable...? > >> >>> + if ( rc < 0 ) >>> + { >>> + gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); >> >> gprintk already dump the domid. So no need to say Dom0. > I just wanted to emphasis that we mappaed memory for Dom0. Will remove. gprintk will printk d0. So there are no point to say it a second time... > >>> + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); >>> + } >>> + >>> + return true; >>> +} >>> + >>> +static bool handle_exchange_capabilities(struct cpu_user_regs *regs) >>> +{ >>> + forward_call(regs); >>> + >>> + printk("handle_exchange_capabilities\n"); >> >> Same here, no plain prink. > Sorry, this is another debug print. Missed it when formatted patches. > >>> + /* Return error back to the guest */ >>> + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>> + return true; >>> + >>> + /* Don't allow guests to work without dynamic SHM */ >> >> Hmmm? But you don't support guests today. So why are you checking that? > This is a RFC. Will remove this parts of the code in a proper patch series. > > I just wanted to ensure that community is okay with proposed approach and > to show how minimalistic mediator can look. I don't think this is true. You only show how easy it is to let Dom0 accessing TEE. And as I said in the cover letter, this is not the controversial part. The more controversial one is the guest support that you completely left aside. I believe this part will not be as minimalistic as you think because you need to translate buffer address and prevent those buffers to disappear under your feet. There are probably other problem to fix... > If you are generally okay with that, I'll address all comments, rework > second patch and push proper patch series. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-17 17:30 ` Julien Grall @ 2017-10-17 18:57 ` Volodymyr Babchuk 2017-10-19 14:01 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-17 18:57 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel On Tue, Oct 17, 2017 at 06:30:13PM +0100, Julien Grall wrote: > >>On 11/10/17 20:01, Volodymyr Babchuk wrote: > >>>Add basic OP-TEE mediator as an example how TEE mediator framework > >>>works. > >>> > >>>Currently it support only calls from Dom0. Calls from other guests > >>>will be declined. It maps OP-TEE static shared memory region into > >>>Dom0 address space, so Dom0 is the only domain which can work with > >>>older versions of OP-TEE. > >>> > >>>Also it alters SMC requests by\ adding domain id to request. OP-TEE > >>>can use this information to track requesters. > >>> > >>>Albeit being in early development stages, this mediator already can > >>>be used on systems where only Dom0 interacts with OP-TEE. > >> > >>A link to the spec would be useful here to be able to fully review this > >>patch. > >Which spec? OP-TEE protocol? It was added in previous commit. > > So basically you are saying the header is the documentation of the API? > There are not external documentation making easier to follow the version...? There are high-level documentation at [1]. All details are covered in headers. > > > >>> > >>>It was tested on RCAR Salvator-M3 board. > >> > >>Is it with the stock op-tee? Or an updated version? > >Static SHM was tested with stock OP-TEE. Dynamic SHM was tested with > >my build. But my patches are already merged. OP-TEE 2.6.0 will support > >dynamic SHM out of the box. > > > >>> > >>>Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >>>--- > >>> xen/arch/arm/tee/Kconfig | 4 ++ > >>> xen/arch/arm/tee/Makefile | 1 + > >>> xen/arch/arm/tee/optee.c | 178 ++++++++++++++++++++++++++++++++++++++++++++++ > >>> 3 files changed, 183 insertions(+) > >>> create mode 100644 xen/arch/arm/tee/optee.c > >>> > >>>diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig > >>>index e69de29..7c6b5c6 100644 > >>>--- a/xen/arch/arm/tee/Kconfig > >>>+++ b/xen/arch/arm/tee/Kconfig > >>>@@ -0,0 +1,4 @@ > >>>+config ARM_OPTEE > >>>+ bool "Enable OP-TEE mediator" > >>>+ default n > >>>+ depends on ARM_TEE > >>>diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile > >>>index c54d479..9d93b42 100644 > >>>--- a/xen/arch/arm/tee/Makefile > >>>+++ b/xen/arch/arm/tee/Makefile > >>>@@ -1 +1,2 @@ > >>> obj-y += tee.o > >>>+obj-$(CONFIG_ARM_OPTEE) += optee.o > >>>diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > >>>new file mode 100644 > >>>index 0000000..0220691 > >>>--- /dev/null > >>>+++ b/xen/arch/arm/tee/optee.c > >>>@@ -0,0 +1,178 @@ > >>>+/* > >>>+ * xen/arch/arm/tee/optee.c > >>>+ * > >>>+ * OP-TEE mediator > >>>+ * > >>>+ * Volodymyr Babchuk <volodymyr_babchuk@epam.com> > >>>+ * Copyright (c) 2017 EPAM Systems. > >>>+ * > >>>+ * This program is free software; you can redistribute it and/or modify > >>>+ * it under the terms of the GNU General Public License version 2 as > >>>+ * published by the Free Software Foundation. > >>>+ * > >>>+ * This program is distributed in the hope that it will be useful, > >>>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of > >>>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >>>+ * GNU General Public License for more details. > >>>+ */ > >>>+ > >>>+#include <xen/types.h> > >>>+#include <xen/sched.h> > >>>+ > >>>+#include <asm/p2m.h> > >>>+#include <asm/tee.h> > >>>+ > >>>+#include "optee_msg.h" > >>>+#include "optee_smc.h" > >>>+ > >>>+/* > >>>+ * OP-TEE violates SMCCC when it defines own UID. So we need > >>>+ * to place bytes in correct order. > >> > >>Can you please point the paragraph in the spec where it says that? > >Sure. > > > >>>+ */ > >>>+#define OPTEE_UID (xen_uuid_t){{ \ > >>>+ (uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8), \ > >>>+ (uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24), \ > >>>+ (uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8), \ > >>>+ (uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24), \ > >>>+ (uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8), \ > >>>+ (uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24), \ > >>>+ (uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8), \ > >>>+ (uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24), \ > >>>+ }} > >>>+ > >>>+static int optee_init(void) > >>>+{ > >>>+ printk("OP-TEE mediator init done\n"); > >>>+ return 0; > >>>+} > >>>+ > >>>+static void optee_domain_create(struct domain *d) > >>>+{ > >>>+ /* > >>>+ * Do nothing at this time. > >>>+ * In the future this function will notify that new VM is started. > >> > >>You already have a new client with the hardware domain. So don't you already > >>need to notifity OP-TEE? > >Because currently OP-TEE does not support such notification. > > > >>>+ */ > >>>+} > >>>+ > >>>+static void optee_domain_destroy(struct domain *d) > >>>+{ > >>>+ /* > >>>+ * Do nothing at this time. > >>>+ * In the future this function will notify that VM is being destroyed. > >>>+ */ > >> > >>Same for the destruction? > >The same answer. OP-TEE currently can work with only one domain. I selected > >Dom0 for this. > > > >>>+} > >>>+ > >>>+static bool forward_call(struct cpu_user_regs *regs) > >>>+{ > >>>+ register_t resp[4]; > >>>+ > >>>+ call_smccc_smc(get_user_reg(regs, 0), > >>>+ get_user_reg(regs, 1), > >>>+ get_user_reg(regs, 2), > >>>+ get_user_reg(regs, 3), > >>>+ get_user_reg(regs, 4), > >>>+ get_user_reg(regs, 5), > >>>+ get_user_reg(regs, 6), > >>>+ /* VM id 0 is reserved for hypervisor itself */ > >> > >>s/VM/client/. Also, on your design document you mentioned that you did > >>modify OP-TEE to support multiple client ID. So how do you know whether the > >>TEE supports client ID? > >Hm, as I remember, I never mentioned that I modified OP-TEE to support > >multiple client IDs. This is my current task. > > "On OP-TEE side: > 1. Shared memory redesign which is almost complete. > 2. Implement new SMCs from hypervsiror to TEE to track VM lifecycle. > 3. Track VM IDs to isolated VM data. > 4. RPCs to sleeping guests." Yes, this are my plans. First item is done. I'm currently working on others. Sorry, looks like I didn't clearly showed, that this is what should be done. It is not done yet. > I was kind of expecting that was done given you put a client ID here. If it > is not done, then why are you passing a ID that we are not even sure OP-TEE > will be able to understand? OP-TEE has very rudimentary support of client ID [2]. So it will understand it. It uses client ID to ensure, that right VM does return from a RPC. There are no other uses for it right now. > >But, answering your question, optee_domain_create() will tell OP-TEE about > >new client ID. > > And I guess you would expect that the registration may fail, hence an error > return is mandatory in optee_domain_create. Agree. > > > >>Similarly, do you expect OP-TEE to support 16-bit of client identifier? > >Actually, yes. But I don't expect it to work with all 65535 domains at the > >same time. > > So how many client do you expect to be supported? And how do you expect to > get that information back? I can't answer to your question right now. OP-TEE has limited memory resources. It need to share them among multiple guests. This is not done yet. So I can't make assumptions yet. > > > >>>+ current->domain->domain_id +1, > >>>+ resp); > >>>+ > >>>+ set_user_reg(regs, 0, resp[0]); > >>>+ set_user_reg(regs, 1, resp[1]); > >>>+ set_user_reg(regs, 2, resp[2]); > >>>+ set_user_reg(regs, 3, resp[3]); > >> > >>Who will do the sanity check of the return values? Each callers? If so, I > >>would prefer that the results are stored in a temporary array and a separate > >>helpers will write them into the domain once the sanity is done. > >Maybe there will be cases when call will be forwarded straight to OP-TEE and > >nobody in hypervisor will examine returned result. At least, at this moment > >there are such cases. Probably, in full-scalle mediator this will no longer > >be true. > > > >>This would avoid to mistakenly expose unwanted data to a domain. > >Correct me, but set_user_reg() modifies data that will be stored in general > >purpose registers during return from trap handler. This can't expose any > >additional data to a domain. > > Which set_user_reg()? The helper does not do any modification... If you > speak about the code below, then it is very confusing and error-prone. No, I was speaking about code above. The one that calls set_user_reg(). You leave your comment there, so I assumed you are talking about that part. > If you separate the call from setting the guest registers then the you give > a hint to the caller that maybe something has to be down and he can't > blindly trust the result... Let me describe how this works right now. XEN traps SMC to OP-TEE and forwards it to the mediator. Mediator examines registers to determine type of the call. Then it either: * Forwards it to OP-TEE as is. This does forward_call(). forward_call() executes real SMC and then writes return data to guest registers * Forwards it to OP-TEE and then examines result. Again, it uses forward_call() to execute SMC and then it checks returned values. For example, if guest wanted to exchange capabilities with OP-TEE, mediator checks if OP-TEE support dynamic SHM. If it is not supported and guest is not hwdom, then mediator injects an error to guest. This prevents further initialization of OP-TEE driver in client. Another example is static SHM configuration. If this request was sent from hwdom, then upon return from OP-TEE, mediator maps static shm into hwdom address space. Else it returns an error. DomU sees that static SHM is not available and relies only on dynamic SHM. Idea is to make this transparent for OP-TEE client driver. It does not need to know that it is running in virtualized environment (one backward-compatible change will be needed anyways, but this is another story). Static SHM is a predefined region, that is shared by OP-TEE OS and OP-TEE client. Both sides expect that it is a physically contiguous memory region. Dynamic SHM is never thing. It allows OP-TEE client to use any portion of own memory as SHM. It was designed with virtualization in mind, so it support non-contiguous memory regions. Thus it can be used by DomU clients. > > > > >>>+ > >>>+ return true; > >>>+} > >>>+ > >>>+static bool handle_get_shm_config(struct cpu_user_regs *regs) > >>>+{ > >>>+ paddr_t shm_start; > >>>+ size_t shm_size; > >>>+ int rc; > >>>+ > >>>+ printk("handle_get_shm_config\n"); > >> > >>No plain printk in code accessible by the guest. You should use gprintk or > >>ratelimit it. > >Sorry, this is a debug print. I'll remove it at all. > > > >>>+ /* Give all static SHM region to the Dom0 */ > >> > >>s/Dom0/Hardware Domain/ > >Hm, looks like Dom0 != hardware domain. At least I see code that replaces > >contents of hardware_domain variable. If it is possible, then there will > >be a problem with static SHM buffer. > > On Arm Dom0 == Hardware Domain. If Hardware Domain were introduced, then I > would expect OP-TEE to be handled by the it and not Dom0. Oh, I see. Thank you for explanation. > > > >Looks like it is better to check for is_domain_direct_mapped(d), as you > >mentioned below. > > is_domain_direct_mapped(d) != hwdom. Please don't mix the both. The former > is here to proctect you gfn == mfn. The latter is here to make sure no other > domain than the hardware domain is going to use the shared memory. Yes, I see. As I said earlier, only 1:1 mapped domain can use static SHM mechanism. So I think I need to use is_domain_direct_mapped(d). > > > >>But I am not sure what's the point of this check given OP-TEE is only > >>supported for the Hardware Domain and you already have a check for that. > >Because I will remove outer check. But this check will remain. In this way > >older OP-TEEs (without virtualization support) will still be accessible > >from Dom0/HWDom. > > > >>>+ if ( current->domain->domain_id != 0 ) > >> > >>Please use is_hardware_domain(current->domain) and not open-code the check. > >> > >>>+ return false; > >>>+ > >>>+ forward_call(regs); > >>>+ > >>>+ /* Return error back to the guest */ > >>>+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) > >>>+ return true; > >> > >>This is quite confusing to read, I think it would make sense that > >>forward_call return the error. > >Good idea, thanks. > > > >>>+ > >>>+ shm_start = get_user_reg(regs, 1); > >>>+ shm_size = get_user_reg(regs, 2); > >>>+ > >>>+ /* Dom0 is mapped 1:1 */ > >> > >>Please don't make this assumption or at least add > >>ASSERT(is_domain_direct_mapped(d)); > >Thanks. I'll check this in runtime, as I mentioned above. > > > >>>+ rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), > >> > >>Rather than using current->domain everywhere, I would prefer if you > >>introduce a temporary variable for the domain. > >Okay. > > > >>>+ shm_size / PAGE_SIZE, > >> > >>Please PFN_DOWN(...). > >> > >>>+ maddr_to_mfn(shm_start), > >>>+ p2m_ram_rw); > >> > >>What is this shared memory for? I know this is the hardware domain, so using > >>p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do > >>proper safety check. > >Linux kernel driver does memremap() in such place. OP-TEE maps it as non-secure > >RAM. This shared memory is used to pass information between OP-TEE OS > >and OP-TEE client. About which safety check you are talking? > > Well, does OP-TEE validate the data read from that shared region? But it > seems that you don't plan to give part of the SHM to a guest, so it might be > ok. OP-TEE surely validate all data from NW. Also OP-TEE is written in such way, that it reads from shared memory only once, to ensure that NW will not change data after validation. Mediator will do the same. > Also how OP-TEE will map this region? Cacheable...? Yes, cacheable, PR, PW, non-secure. > > > >> > >>>+ if ( rc < 0 ) > >>>+ { > >>>+ gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); > >> > >>gprintk already dump the domid. So no need to say Dom0. > >I just wanted to emphasis that we mappaed memory for Dom0. Will remove. > > gprintk will printk d0. So there are no point to say it a second time... > > > >>>+ set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); > >>>+ } > >>>+ > >>>+ return true; > >>>+} > >>>+ > >>>+static bool handle_exchange_capabilities(struct cpu_user_regs *regs) > >>>+{ > >>>+ forward_call(regs); > >>>+ > >>>+ printk("handle_exchange_capabilities\n"); > >> > >>Same here, no plain prink. > >Sorry, this is another debug print. Missed it when formatted patches. > > > >>>+ /* Return error back to the guest */ > >>>+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) > >>>+ return true; > >>>+ > >>>+ /* Don't allow guests to work without dynamic SHM */ > >> > >>Hmmm? But you don't support guests today. So why are you checking that? > >This is a RFC. Will remove this parts of the code in a proper patch series. > > > >I just wanted to ensure that community is okay with proposed approach and > >to show how minimalistic mediator can look. > I don't think this is true. You only show how easy it is to let Dom0 > accessing TEE. And as I said in the cover letter, this is not the > controversial part. Actually I wanted to show approach when mediator resides right in xen. I got valuable input from you. Now I see that I must completely rework the first patch. And, probably, show more comprehensive support from OP-TEE side. > The more controversial one is the guest support that you completely left > aside. I believe this part will not be as minimalistic as you think because > you need to translate buffer address and prevent those buffers to disappear > under your feet. Yes. I plan to copy all buffers where IPAs presented to another place, so DomU will not be able to see PAs during translation. And I plan to pin all DomU pages with a data. Also I'll read from guest pages only once. I think, this will be enough. > There are probably other problem to fix... Probably yes... I think, I'll focus on OP-TEE side right now and come back when there will be more more to show. [1] https://github.com/OP-TEE/optee_os/blob/master/documentation/optee_design.md [2] https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/thread.c#L459 WBR, Volodymyr. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-17 18:57 ` Volodymyr Babchuk @ 2017-10-19 14:01 ` Julien Grall 2017-10-19 15:33 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-19 14:01 UTC (permalink / raw) To: Volodymyr Babchuk Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel Hi Volodymyr, On 17/10/17 19:57, Volodymyr Babchuk wrote: > On Tue, Oct 17, 2017 at 06:30:13PM +0100, Julien Grall wrote: > >>>> On 11/10/17 20:01, Volodymyr Babchuk wrote: >>>>> Add basic OP-TEE mediator as an example how TEE mediator framework >>>>> works. >>>>> >>>>> Currently it support only calls from Dom0. Calls from other guests >>>>> will be declined. It maps OP-TEE static shared memory region into >>>>> Dom0 address space, so Dom0 is the only domain which can work with >>>>> older versions of OP-TEE. >>>>> >>>>> Also it alters SMC requests by\ adding domain id to request. OP-TEE >>>>> can use this information to track requesters. >>>>> >>>>> Albeit being in early development stages, this mediator already can >>>>> be used on systems where only Dom0 interacts with OP-TEE. >>>> >>>> A link to the spec would be useful here to be able to fully review this >>>> patch. >>> Which spec? OP-TEE protocol? It was added in previous commit. >> >> So basically you are saying the header is the documentation of the API? >> There are not external documentation making easier to follow the version...? > There are high-level documentation at [1]. All details are covered in headers. Thanks. > >>> >>>>> >>>>> It was tested on RCAR Salvator-M3 board. >>>> >>>> Is it with the stock op-tee? Or an updated version? >>> Static SHM was tested with stock OP-TEE. Dynamic SHM was tested with >>> my build. But my patches are already merged. OP-TEE 2.6.0 will support >>> dynamic SHM out of the box. >>> >>>>> >>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>>>> --- >>>>> xen/arch/arm/tee/Kconfig | 4 ++ >>>>> xen/arch/arm/tee/Makefile | 1 + >>>>> xen/arch/arm/tee/optee.c | 178 ++++++++++++++++++++++++++++++++++++++++++++++ >>>>> 3 files changed, 183 insertions(+) >>>>> create mode 100644 xen/arch/arm/tee/optee.c >>>>> >>>>> diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig >>>>> index e69de29..7c6b5c6 100644 >>>>> --- a/xen/arch/arm/tee/Kconfig >>>>> +++ b/xen/arch/arm/tee/Kconfig >>>>> @@ -0,0 +1,4 @@ >>>>> +config ARM_OPTEE >>>>> + bool "Enable OP-TEE mediator" >>>>> + default n >>>>> + depends on ARM_TEE >>>>> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile >>>>> index c54d479..9d93b42 100644 >>>>> --- a/xen/arch/arm/tee/Makefile >>>>> +++ b/xen/arch/arm/tee/Makefile >>>>> @@ -1 +1,2 @@ >>>>> obj-y += tee.o >>>>> +obj-$(CONFIG_ARM_OPTEE) += optee.o >>>>> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c >>>>> new file mode 100644 >>>>> index 0000000..0220691 >>>>> --- /dev/null >>>>> +++ b/xen/arch/arm/tee/optee.c >>>>> @@ -0,0 +1,178 @@ >>>>> +/* >>>>> + * xen/arch/arm/tee/optee.c >>>>> + * >>>>> + * OP-TEE mediator >>>>> + * >>>>> + * Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>>>> + * Copyright (c) 2017 EPAM Systems. >>>>> + * >>>>> + * This program is free software; you can redistribute it and/or modify >>>>> + * it under the terms of the GNU General Public License version 2 as >>>>> + * published by the Free Software Foundation. >>>>> + * >>>>> + * This program is distributed in the hope that it will be useful, >>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>>> + * GNU General Public License for more details. >>>>> + */ >>>>> + >>>>> +#include <xen/types.h> >>>>> +#include <xen/sched.h> >>>>> + >>>>> +#include <asm/p2m.h> >>>>> +#include <asm/tee.h> >>>>> + >>>>> +#include "optee_msg.h" >>>>> +#include "optee_smc.h" >>>>> + >>>>> +/* >>>>> + * OP-TEE violates SMCCC when it defines own UID. So we need >>>>> + * to place bytes in correct order. >>>> >>>> Can you please point the paragraph in the spec where it says that? >>> Sure. >>> >>>>> + */ >>>>> +#define OPTEE_UID (xen_uuid_t){{ \ >>>>> + (uint8_t)(OPTEE_MSG_UID_0 >> 0), (uint8_t)(OPTEE_MSG_UID_0 >> 8), \ >>>>> + (uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24), \ >>>>> + (uint8_t)(OPTEE_MSG_UID_1 >> 0), (uint8_t)(OPTEE_MSG_UID_1 >> 8), \ >>>>> + (uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24), \ >>>>> + (uint8_t)(OPTEE_MSG_UID_2 >> 0), (uint8_t)(OPTEE_MSG_UID_2 >> 8), \ >>>>> + (uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24), \ >>>>> + (uint8_t)(OPTEE_MSG_UID_3 >> 0), (uint8_t)(OPTEE_MSG_UID_3 >> 8), \ >>>>> + (uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24), \ >>>>> + }} >>>>> + >>>>> +static int optee_init(void) >>>>> +{ >>>>> + printk("OP-TEE mediator init done\n"); >>>>> + return 0; >>>>> +} >>>>> + >>>>> +static void optee_domain_create(struct domain *d) >>>>> +{ >>>>> + /* >>>>> + * Do nothing at this time. >>>>> + * In the future this function will notify that new VM is started. >>>> >>>> You already have a new client with the hardware domain. So don't you already >>>> need to notifity OP-TEE? >>> Because currently OP-TEE does not support such notification. >>> >>>>> + */ >>>>> +} >>>>> + >>>>> +static void optee_domain_destroy(struct domain *d) >>>>> +{ >>>>> + /* >>>>> + * Do nothing at this time. >>>>> + * In the future this function will notify that VM is being destroyed. >>>>> + */ >>>> >>>> Same for the destruction? >>> The same answer. OP-TEE currently can work with only one domain. I selected >>> Dom0 for this. >>> >>>>> +} >>>>> + >>>>> +static bool forward_call(struct cpu_user_regs *regs) >>>>> +{ >>>>> + register_t resp[4]; >>>>> + >>>>> + call_smccc_smc(get_user_reg(regs, 0), >>>>> + get_user_reg(regs, 1), >>>>> + get_user_reg(regs, 2), >>>>> + get_user_reg(regs, 3), >>>>> + get_user_reg(regs, 4), >>>>> + get_user_reg(regs, 5), >>>>> + get_user_reg(regs, 6), >>>>> + /* VM id 0 is reserved for hypervisor itself */ >>>> >>>> s/VM/client/. Also, on your design document you mentioned that you did >>>> modify OP-TEE to support multiple client ID. So how do you know whether the >>>> TEE supports client ID? >>> Hm, as I remember, I never mentioned that I modified OP-TEE to support >>> multiple client IDs. This is my current task. >> >> "On OP-TEE side: >> 1. Shared memory redesign which is almost complete. >> 2. Implement new SMCs from hypervsiror to TEE to track VM lifecycle. >> 3. Track VM IDs to isolated VM data. >> 4. RPCs to sleeping guests." > Yes, this are my plans. First item is done. I'm currently working on > others. Sorry, looks like I didn't clearly showed, that this is what should > be done. It is not done yet. > >> I was kind of expecting that was done given you put a client ID here. If it >> is not done, then why are you passing a ID that we are not even sure OP-TEE >> will be able to understand? > OP-TEE has very rudimentary support of client ID [2]. So it will understand it. > It uses client ID to ensure, that right VM does return from a RPC. There are > no other uses for it right now. I am not sure to understand what you mean here. Do you expect OP-TEE to block? Or send an interrupt later on to say the work is finish? [...] >>> >>>>> + current->domain->domain_id +1, >>>>> + resp); >>>>> + >>>>> + set_user_reg(regs, 0, resp[0]); >>>>> + set_user_reg(regs, 1, resp[1]); >>>>> + set_user_reg(regs, 2, resp[2]); >>>>> + set_user_reg(regs, 3, resp[3]); >>>> >>>> Who will do the sanity check of the return values? Each callers? If so, I >>>> would prefer that the results are stored in a temporary array and a separate >>>> helpers will write them into the domain once the sanity is done. >>> Maybe there will be cases when call will be forwarded straight to OP-TEE and >>> nobody in hypervisor will examine returned result. At least, at this moment >>> there are such cases. Probably, in full-scalle mediator this will no longer >>> be true. >>> >>>> This would avoid to mistakenly expose unwanted data to a domain. >>> Correct me, but set_user_reg() modifies data that will be stored in general >>> purpose registers during return from trap handler. This can't expose any >>> additional data to a domain. >> >> Which set_user_reg()? The helper does not do any modification... If you >> speak about the code below, then it is very confusing and error-prone. > No, I was speaking about code above. The one that calls set_user_reg(). > You leave your comment there, so I assumed you are talking about that part. > >> If you separate the call from setting the guest registers then the you give >> a hint to the caller that maybe something has to be down and he can't >> blindly trust the result... > Let me describe how this works right now. XEN traps SMC to OP-TEE and forwards > it to the mediator. Mediator examines registers to determine type of the call. > Then it either: > > * Forwards it to OP-TEE as is. This does forward_call(). forward_call() > executes real SMC and then writes return data to guest registers > > * Forwards it to OP-TEE and then examines result. Again, it uses > forward_call() to execute SMC and then it checks returned values. > > For example, if guest wanted to exchange capabilities with OP-TEE, > mediator checks if OP-TEE support dynamic SHM. If it is not supported > and guest is not hwdom, then mediator injects an error to guest. > This prevents further initialization of OP-TEE driver in client. > > Another example is static SHM configuration. If this request was sent > from hwdom, then upon return from OP-TEE, mediator maps static > shm into hwdom address space. Else it returns an error. DomU sees > that static SHM is not available and relies only on dynamic SHM. > > Idea is to make this transparent for OP-TEE client driver. It does not > need to know that it is running in virtualized environment (one > backward-compatible change will be needed anyways, but this is > another story). > > Static SHM is a predefined region, that is shared by OP-TEE OS and OP-TEE client. > Both sides expect that it is a physically contiguous memory region. > Dynamic SHM is never thing. It allows OP-TEE client to use any portion of own > memory as SHM. It was designed with virtualization in mind, so it support > non-contiguous memory regions. Thus it can be used by DomU clients. Thank you for the explanation, but I don't think this is addressing how this would prevent leaking data to the guest. My request is to move the set_user_reg(...) calls outside of call_forward. So this would make clear the mediator needs to examine the result values. To give you an example: call_forward(....) /* No need to sanitize value because... */ set_user_reg(...) set_user_reg(...) The caller may not need to examine the results. But at least it is clear compare to an helper hiding that. Note that the set_user_reg(...) calls could in a another helper. >> >>> >>>>> + >>>>> + return true; >>>>> +} >>>>> + >>>>> +static bool handle_get_shm_config(struct cpu_user_regs *regs) >>>>> +{ >>>>> + paddr_t shm_start; >>>>> + size_t shm_size; >>>>> + int rc; >>>>> + >>>>> + printk("handle_get_shm_config\n"); >>>> >>>> No plain printk in code accessible by the guest. You should use gprintk or >>>> ratelimit it. >>> Sorry, this is a debug print. I'll remove it at all. >>> >>>>> + /* Give all static SHM region to the Dom0 */ >>>> >>>> s/Dom0/Hardware Domain/ >>> Hm, looks like Dom0 != hardware domain. At least I see code that replaces >>> contents of hardware_domain variable. If it is possible, then there will >>> be a problem with static SHM buffer. >> >> On Arm Dom0 == Hardware Domain. If Hardware Domain were introduced, then I >> would expect OP-TEE to be handled by the it and not Dom0. > Oh, I see. Thank you for explanation. > >>> >>> Looks like it is better to check for is_domain_direct_mapped(d), as you >>> mentioned below. >> >> is_domain_direct_mapped(d) != hwdom. Please don't mix the both. The former >> is here to proctect you gfn == mfn. The latter is here to make sure no other >> domain than the hardware domain is going to use the shared memory. > Yes, I see. As I said earlier, only 1:1 mapped domain can use static SHM > mechanism. So I think I need to use is_domain_direct_mapped(d). But if you use is_domain_direct_mapped(d) here, what will happen if two guests asked for shared memory? > >>> >>>> But I am not sure what's the point of this check given OP-TEE is only >>>> supported for the Hardware Domain and you already have a check for that. >>> Because I will remove outer check. But this check will remain. In this way >>> older OP-TEEs (without virtualization support) will still be accessible >> >from Dom0/HWDom. >>> >>>>> + if ( current->domain->domain_id != 0 ) >>>> >>>> Please use is_hardware_domain(current->domain) and not open-code the check. >>>> >>>>> + return false; >>>>> + >>>>> + forward_call(regs); >>>>> + >>>>> + /* Return error back to the guest */ >>>>> + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>>>> + return true; >>>> >>>> This is quite confusing to read, I think it would make sense that >>>> forward_call return the error. >>> Good idea, thanks. >>> >>>>> + >>>>> + shm_start = get_user_reg(regs, 1); >>>>> + shm_size = get_user_reg(regs, 2); >>>>> + >>>>> + /* Dom0 is mapped 1:1 */ >>>> >>>> Please don't make this assumption or at least add >>>> ASSERT(is_domain_direct_mapped(d)); >>> Thanks. I'll check this in runtime, as I mentioned above. >>> >>>>> + rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), >>>> >>>> Rather than using current->domain everywhere, I would prefer if you >>>> introduce a temporary variable for the domain. >>> Okay. >>> >>>>> + shm_size / PAGE_SIZE, >>>> >>>> Please PFN_DOWN(...). >>>> >>>>> + maddr_to_mfn(shm_start), >>>>> + p2m_ram_rw); >>>> >>>> What is this shared memory for? I know this is the hardware domain, so using >>>> p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do >>>> proper safety check. >>> Linux kernel driver does memremap() in such place. OP-TEE maps it as non-secure >>> RAM. This shared memory is used to pass information between OP-TEE OS >>> and OP-TEE client. About which safety check you are talking? >> >> Well, does OP-TEE validate the data read from that shared region? But it >> seems that you don't plan to give part of the SHM to a guest, so it might be >> ok. > OP-TEE surely validate all data from NW. Also OP-TEE is written in such way, > that it reads from shared memory only once, to ensure that NW will not change > data after validation. Mediator will do the same. What do you mean by the last bit? > >> Also how OP-TEE will map this region? Cacheable...? > Yes, cacheable, PR, PW, non-secure. > >>> >>>> >>>>> + if ( rc < 0 ) >>>>> + { >>>>> + gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); >>>> >>>> gprintk already dump the domid. So no need to say Dom0. >>> I just wanted to emphasis that we mappaed memory for Dom0. Will remove. >> >> gprintk will printk d0. So there are no point to say it a second time... >>> >>>>> + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); >>>>> + } >>>>> + >>>>> + return true; >>>>> +} >>>>> + >>>>> +static bool handle_exchange_capabilities(struct cpu_user_regs *regs) >>>>> +{ >>>>> + forward_call(regs); >>>>> + >>>>> + printk("handle_exchange_capabilities\n"); >>>> >>>> Same here, no plain prink. >>> Sorry, this is another debug print. Missed it when formatted patches. >>> >>>>> + /* Return error back to the guest */ >>>>> + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>>>> + return true; >>>>> + >>>>> + /* Don't allow guests to work without dynamic SHM */ >>>> >>>> Hmmm? But you don't support guests today. So why are you checking that? >>> This is a RFC. Will remove this parts of the code in a proper patch series. >>> >>> I just wanted to ensure that community is okay with proposed approach and >>> to show how minimalistic mediator can look. >> I don't think this is true. You only show how easy it is to let Dom0 >> accessing TEE. And as I said in the cover letter, this is not the >> controversial part. > Actually I wanted to show approach when mediator resides right in xen. > I got valuable input from you. Now I see that I must completely rework the > first patch. And, probably, show more comprehensive support from OP-TEE side. > >> The more controversial one is the guest support that you completely left >> aside. I believe this part will not be as minimalistic as you think because >> you need to translate buffer address and prevent those buffers to disappear >> under your feet. > Yes. I plan to copy all buffers where IPAs presented to another place, > so DomU will not be able to see PAs during translation. And I plan to > pin all DomU pages with a data. Also I'll read from guest pages only > once. I think, this will be enough. > >> There are probably other problem to fix... > Probably yes... > > I think, I'll focus on OP-TEE side right now and come back when there will > be more more to show. To clarify my view. I am not against a temporary support of OP-TEE for the hardware domain in Xen. But it does not mean I would be ready to see the a full OP-TEE support for guests in Xen. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-19 14:01 ` Julien Grall @ 2017-10-19 15:33 ` Volodymyr Babchuk 2017-10-19 16:12 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-19 15:33 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel On Thu, Oct 19, 2017 at 03:01:28PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, [...] >>>>>>+} >>>>>>+ >>>>>>+static bool forward_call(struct cpu_user_regs *regs) >>>>>>+{ >>>>>>+ register_t resp[4]; >>>>>>+ >>>>>>+ call_smccc_smc(get_user_reg(regs, 0), >>>>>>+ get_user_reg(regs, 1), >>>>>>+ get_user_reg(regs, 2), >>>>>>+ get_user_reg(regs, 3), >>>>>>+ get_user_reg(regs, 4), >>>>>>+ get_user_reg(regs, 5), >>>>>>+ get_user_reg(regs, 6), >>>>>>+ /* VM id 0 is reserved for hypervisor itself */ >>>>> >>>>>s/VM/client/. Also, on your design document you mentioned that you did >>>>>modify OP-TEE to support multiple client ID. So how do you know whether the >>>>>TEE supports client ID? >>>>Hm, as I remember, I never mentioned that I modified OP-TEE to support >>>>multiple client IDs. This is my current task. >>> >>>"On OP-TEE side: >>>1. Shared memory redesign which is almost complete. >>>2. Implement new SMCs from hypervsiror to TEE to track VM lifecycle. >>>3. Track VM IDs to isolated VM data. >>>4. RPCs to sleeping guests." >>Yes, this are my plans. First item is done. I'm currently working on >>others. Sorry, looks like I didn't clearly showed, that this is what should >>be done. It is not done yet. >> >>>I was kind of expecting that was done given you put a client ID here. If it >>>is not done, then why are you passing a ID that we are not even sure OP-TEE >>>will be able to understand? >>OP-TEE has very rudimentary support of client ID [2]. So it will understand it. >>It uses client ID to ensure, that right VM does return from a RPC. There are >>no other uses for it right now. > > I am not sure to understand what you mean here. Do you expect OP-TEE to > block? Or send an interrupt later on to say the work is finish? No, OP-TEE will never block in Secure World. Roughty mechanism of RPCs is described on page 19 of SMCCC. It is called "yielding service call" in SMCCC. OP-TEE uses client id ensure that resume_call() from one VM does not mimick resume_call() from other VM. There are more checks, obvioulsy. This is one of them. > [...] > >>>> >>>>>>+ current->domain->domain_id +1, >>>>>>+ resp); >>>>>>+ >>>>>>+ set_user_reg(regs, 0, resp[0]); >>>>>>+ set_user_reg(regs, 1, resp[1]); >>>>>>+ set_user_reg(regs, 2, resp[2]); >>>>>>+ set_user_reg(regs, 3, resp[3]); >>>>> >>>>>Who will do the sanity check of the return values? Each callers? If so, I >>>>>would prefer that the results are stored in a temporary array and a separate >>>>>helpers will write them into the domain once the sanity is done. >>>>Maybe there will be cases when call will be forwarded straight to OP-TEE and >>>>nobody in hypervisor will examine returned result. At least, at this moment >>>>there are such cases. Probably, in full-scalle mediator this will no longer >>>>be true. >>>> >>>>>This would avoid to mistakenly expose unwanted data to a domain. >>>>Correct me, but set_user_reg() modifies data that will be stored in general >>>>purpose registers during return from trap handler. This can't expose any >>>>additional data to a domain. >>> >>>Which set_user_reg()? The helper does not do any modification... If you >>>speak about the code below, then it is very confusing and error-prone. >>No, I was speaking about code above. The one that calls set_user_reg(). >>You leave your comment there, so I assumed you are talking about that part. >> >>>If you separate the call from setting the guest registers then the you give >>>a hint to the caller that maybe something has to be down and he can't >>>blindly trust the result... >>Let me describe how this works right now. XEN traps SMC to OP-TEE and forwards >>it to the mediator. Mediator examines registers to determine type of the call. >>Then it either: >> >> * Forwards it to OP-TEE as is. This does forward_call(). forward_call() >> executes real SMC and then writes return data to guest registers >> >> * Forwards it to OP-TEE and then examines result. Again, it uses >> forward_call() to execute SMC and then it checks returned values. >> >> For example, if guest wanted to exchange capabilities with OP-TEE, >> mediator checks if OP-TEE support dynamic SHM. If it is not supported >> and guest is not hwdom, then mediator injects an error to guest. >> This prevents further initialization of OP-TEE driver in client. >> >> Another example is static SHM configuration. If this request was sent >> from hwdom, then upon return from OP-TEE, mediator maps static >> shm into hwdom address space. Else it returns an error. DomU sees >> that static SHM is not available and relies only on dynamic SHM. >> >>Idea is to make this transparent for OP-TEE client driver. It does not >>need to know that it is running in virtualized environment (one >>backward-compatible change will be needed anyways, but this is >>another story). >> >>Static SHM is a predefined region, that is shared by OP-TEE OS and OP-TEE client. >>Both sides expect that it is a physically contiguous memory region. >>Dynamic SHM is never thing. It allows OP-TEE client to use any portion of own >>memory as SHM. It was designed with virtualization in mind, so it support >>non-contiguous memory regions. Thus it can be used by DomU clients. > Thank you for the explanation, but I don't think this is addressing how this > would prevent leaking data to the guest. Oh, it just hitted me. I change values in x0/r0 when I want to emit an error, but I leave other registers as is. This is good point. Thank you. > My request is to move the set_user_reg(...) calls outside of call_forward. > So this would make clear the mediator needs to examine the result values. Ah, I see. You suggest to rename forward_call() to something like execute_call() and make it return result in some other way. > To give you an example: > > call_forward(....) > /* No need to sanitize value because... */ > set_user_reg(...) > set_user_reg(...) > > The caller may not need to examine the results. But at least it is clear > compare to an helper hiding that. > > Note that the set_user_reg(...) calls could in a another helper. Yep. So new executute_call() call does actuall SMC and returns result in some structure. If I need to return result as is back to VM, I call another helper. Right? >>> >>>> >>>>>>+ >>>>>>+ return true; >>>>>>+} >>>>>>+ >>>>>>+static bool handle_get_shm_config(struct cpu_user_regs *regs) >>>>>>+{ >>>>>>+ paddr_t shm_start; >>>>>>+ size_t shm_size; >>>>>>+ int rc; >>>>>>+ >>>>>>+ printk("handle_get_shm_config\n"); >>>>> >>>>>No plain printk in code accessible by the guest. You should use gprintk or >>>>>ratelimit it. >>>>Sorry, this is a debug print. I'll remove it at all. >>>> >>>>>>+ /* Give all static SHM region to the Dom0 */ >>>>> >>>>>s/Dom0/Hardware Domain/ >>>>Hm, looks like Dom0 != hardware domain. At least I see code that replaces >>>>contents of hardware_domain variable. If it is possible, then there will >>>>be a problem with static SHM buffer. >>> >>>On Arm Dom0 == Hardware Domain. If Hardware Domain were introduced, then I >>>would expect OP-TEE to be handled by the it and not Dom0. >>Oh, I see. Thank you for explanation. >> >>>> >>>>Looks like it is better to check for is_domain_direct_mapped(d), as you >>>>mentioned below. >>> >>>is_domain_direct_mapped(d) != hwdom. Please don't mix the both. The former >>>is here to proctect you gfn == mfn. The latter is here to make sure no other >>>domain than the hardware domain is going to use the shared memory. >>Yes, I see. As I said earlier, only 1:1 mapped domain can use static SHM >>mechanism. So I think I need to use is_domain_direct_mapped(d). > > But if you use is_domain_direct_mapped(d) here, what will happen if two > guests asked for shared memory? Is is possible that there will be two 1:1 mapped domains in XEN? If yes, then I need to employ both checks: is_domain_direct_mapped(d) && is_hardware_domain(d). >> >>>> >>>>>But I am not sure what's the point of this check given OP-TEE is only >>>>>supported for the Hardware Domain and you already have a check for that. >>>>Because I will remove outer check. But this check will remain. In this way >>>>older OP-TEEs (without virtualization support) will still be accessible >>>>from Dom0/HWDom. >>>> >>>>>>+ if ( current->domain->domain_id != 0 ) >>>>> >>>>>Please use is_hardware_domain(current->domain) and not open-code the check. >>>>> >>>>>>+ return false; >>>>>>+ >>>>>>+ forward_call(regs); >>>>>>+ >>>>>>+ /* Return error back to the guest */ >>>>>>+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>>>>>+ return true; >>>>> >>>>>This is quite confusing to read, I think it would make sense that >>>>>forward_call return the error. >>>>Good idea, thanks. >>>> >>>>>>+ >>>>>>+ shm_start = get_user_reg(regs, 1); >>>>>>+ shm_size = get_user_reg(regs, 2); >>>>>>+ >>>>>>+ /* Dom0 is mapped 1:1 */ >>>>> >>>>>Please don't make this assumption or at least add >>>>>ASSERT(is_domain_direct_mapped(d)); >>>>Thanks. I'll check this in runtime, as I mentioned above. >>>> >>>>>>+ rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), >>>>> >>>>>Rather than using current->domain everywhere, I would prefer if you >>>>>introduce a temporary variable for the domain. >>>>Okay. >>>> >>>>>>+ shm_size / PAGE_SIZE, >>>>> >>>>>Please PFN_DOWN(...). >>>>> >>>>>>+ maddr_to_mfn(shm_start), >>>>>>+ p2m_ram_rw); >>>>> >>>>>What is this shared memory for? I know this is the hardware domain, so using >>>>>p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do >>>>>proper safety check. >>>>Linux kernel driver does memremap() in such place. OP-TEE maps it as non-secure >>>>RAM. This shared memory is used to pass information between OP-TEE OS >>>>and OP-TEE client. About which safety check you are talking? >>> >>>Well, does OP-TEE validate the data read from that shared region? But it >>>seems that you don't plan to give part of the SHM to a guest, so it might be >>>ok. >>OP-TEE surely validate all data from NW. Also OP-TEE is written in such way, >>that it reads from shared memory only once, to ensure that NW will not change >>data after validation. Mediator will do the same. > > What do you mean by the last bit? Let me cite TEE Internal Core API Specification (Public Release v1.1.1): " The fact that Memory References may use memory directly shared with the client implies that the Trusted Application needs to be especially careful when handling such data: Even if the client is not allowed to access the shared memory buffer during an operation on this buffer, the Trusted OS usually cannot enforce this restriction. A badly-designed or rogue client may well change the content of the shared memory buffer at any time, even between two consecutive memory accesses by the Trusted Application. This means that the Trusted Application needs to be carefully written to avoid any security problem if this happens. If values in the buffer are security critical, the Trusted Application SHOULD always read data only once from a shared buffer and then validate it. It MUST NOT assume that data written to the buffer can be read unchanged later on. " This requirement is for Trusted Applications, but it also true for TEE OS as a whole and also for TEE mediators as well. I just wanted to say, that I plan to write mediator in accordance to this. >> >>>Also how OP-TEE will map this region? Cacheable...? >>Yes, cacheable, PR, PW, non-secure. >> >>>> >>>>> >>>>>>+ if ( rc < 0 ) >>>>>>+ { >>>>>>+ gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); >>>>> >>>>>gprintk already dump the domid. So no need to say Dom0. >>>>I just wanted to emphasis that we mappaed memory for Dom0. Will remove. >>> >>>gprintk will printk d0. So there are no point to say it a second time... >>>> >>>>>>+ set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); >>>>>>+ } >>>>>>+ >>>>>>+ return true; >>>>>>+} >>>>>>+ >>>>>>+static bool handle_exchange_capabilities(struct cpu_user_regs *regs) >>>>>>+{ >>>>>>+ forward_call(regs); >>>>>>+ >>>>>>+ printk("handle_exchange_capabilities\n"); >>>>> >>>>>Same here, no plain prink. >>>>Sorry, this is another debug print. Missed it when formatted patches. >>>> >>>>>>+ /* Return error back to the guest */ >>>>>>+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>>>>>+ return true; >>>>>>+ >>>>>>+ /* Don't allow guests to work without dynamic SHM */ >>>>> >>>>>Hmmm? But you don't support guests today. So why are you checking that? >>>>This is a RFC. Will remove this parts of the code in a proper patch series. >>>> >>>>I just wanted to ensure that community is okay with proposed approach and >>>>to show how minimalistic mediator can look. >>>I don't think this is true. You only show how easy it is to let Dom0 >>>accessing TEE. And as I said in the cover letter, this is not the >>>controversial part. >>Actually I wanted to show approach when mediator resides right in xen. >>I got valuable input from you. Now I see that I must completely rework the >>first patch. And, probably, show more comprehensive support from OP-TEE side. >> >>>The more controversial one is the guest support that you completely left >>>aside. I believe this part will not be as minimalistic as you think because >>>you need to translate buffer address and prevent those buffers to disappear >>>under your feet. >>Yes. I plan to copy all buffers where IPAs presented to another place, >>so DomU will not be able to see PAs during translation. And I plan to >>pin all DomU pages with a data. Also I'll read from guest pages only >>once. I think, this will be enough. >> >>>There are probably other problem to fix... >>Probably yes... >> >>I think, I'll focus on OP-TEE side right now and come back when there will >>be more more to show. > > To clarify my view. I am not against a temporary support of OP-TEE for the > hardware domain in Xen. But it does not mean I would be ready to see the a > full OP-TEE support for guests in Xen. Hm. What did you mean in last sentence? Our (here, at EPAM) target is full virtualization support for OP-TEE. If you don't want to see it in Xen, then what another ways we have? WBR, Volodymyr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-19 15:33 ` Volodymyr Babchuk @ 2017-10-19 16:12 ` Julien Grall 2017-10-19 16:37 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-19 16:12 UTC (permalink / raw) To: Volodymyr Babchuk Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel Hi Volodymyr, On 19/10/17 16:33, Volodymyr Babchuk wrote: > On Thu, Oct 19, 2017 at 03:01:28PM +0100, Julien Grall wrote: >> My request is to move the set_user_reg(...) calls outside of call_forward. >> So this would make clear the mediator needs to examine the result values. > Ah, I see. You suggest to rename forward_call() to something like execute_call() > and make it return result in some other way. > >> To give you an example: >> >> call_forward(....) >> /* No need to sanitize value because... */ >> set_user_reg(...) >> set_user_reg(...) >> >> The caller may not need to examine the results. But at least it is clear >> compare to an helper hiding that. >> >> Note that the set_user_reg(...) calls could in a another helper. > Yep. So new executute_call() call does actuall SMC and returns result in > some structure. If I need to return result as is back to VM, I call another > helper. Right? That's right. > >>>> >>>>> >>>>>>> + >>>>>>> + return true; >>>>>>> +} >>>>>>> + >>>>>>> +static bool handle_get_shm_config(struct cpu_user_regs *regs) >>>>>>> +{ >>>>>>> + paddr_t shm_start; >>>>>>> + size_t shm_size; >>>>>>> + int rc; >>>>>>> + >>>>>>> + printk("handle_get_shm_config\n"); >>>>>> >>>>>> No plain printk in code accessible by the guest. You should use gprintk or >>>>>> ratelimit it. >>>>> Sorry, this is a debug print. I'll remove it at all. >>>>> >>>>>>> + /* Give all static SHM region to the Dom0 */ >>>>>> >>>>>> s/Dom0/Hardware Domain/ >>>>> Hm, looks like Dom0 != hardware domain. At least I see code that replaces >>>>> contents of hardware_domain variable. If it is possible, then there will >>>>> be a problem with static SHM buffer. >>>> >>>> On Arm Dom0 == Hardware Domain. If Hardware Domain were introduced, then I >>>> would expect OP-TEE to be handled by the it and not Dom0. >>> Oh, I see. Thank you for explanation. >>> >>>>> >>>>> Looks like it is better to check for is_domain_direct_mapped(d), as you >>>>> mentioned below. >>>> >>>> is_domain_direct_mapped(d) != hwdom. Please don't mix the both. The former >>>> is here to proctect you gfn == mfn. The latter is here to make sure no other >>>> domain than the hardware domain is going to use the shared memory. >>> Yes, I see. As I said earlier, only 1:1 mapped domain can use static SHM >>> mechanism. So I think I need to use is_domain_direct_mapped(d). >> >> But if you use is_domain_direct_mapped(d) here, what will happen if two >> guests asked for shared memory? > Is is possible that there will be two 1:1 mapped domains in XEN? If yes, > then I need to employ both checks: is_domain_direct_mapped(d) && > is_hardware_domain(d). At the moment only the hardware domain is mapped 1:1. But I don't want to make that assumption in the code. For instance, I know that one of your colleagues was looking at guest mapped 1:1. > >>> >>>>> >>>>>> But I am not sure what's the point of this check given OP-TEE is only >>>>>> supported for the Hardware Domain and you already have a check for that. >>>>> Because I will remove outer check. But this check will remain. In this way >>>>> older OP-TEEs (without virtualization support) will still be accessible >>>> >from Dom0/HWDom. >>>>> >>>>>>> + if ( current->domain->domain_id != 0 ) >>>>>> >>>>>> Please use is_hardware_domain(current->domain) and not open-code the check. >>>>>> >>>>>>> + return false; >>>>>>> + >>>>>>> + forward_call(regs); >>>>>>> + >>>>>>> + /* Return error back to the guest */ >>>>>>> + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>>>>>> + return true; >>>>>> >>>>>> This is quite confusing to read, I think it would make sense that >>>>>> forward_call return the error. >>>>> Good idea, thanks. >>>>> >>>>>>> + >>>>>>> + shm_start = get_user_reg(regs, 1); >>>>>>> + shm_size = get_user_reg(regs, 2); >>>>>>> + >>>>>>> + /* Dom0 is mapped 1:1 */ >>>>>> >>>>>> Please don't make this assumption or at least add >>>>>> ASSERT(is_domain_direct_mapped(d)); >>>>> Thanks. I'll check this in runtime, as I mentioned above. >>>>> >>>>>>> + rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start), >>>>>> >>>>>> Rather than using current->domain everywhere, I would prefer if you >>>>>> introduce a temporary variable for the domain. >>>>> Okay. >>>>> >>>>>>> + shm_size / PAGE_SIZE, >>>>>> >>>>>> Please PFN_DOWN(...). >>>>>> >>>>>>> + maddr_to_mfn(shm_start), >>>>>>> + p2m_ram_rw); >>>>>> >>>>>> What is this shared memory for? I know this is the hardware domain, so using >>>>>> p2m_ram_rw would be ok. But I don't think this would be safe unless TEE do >>>>>> proper safety check. >>>>> Linux kernel driver does memremap() in such place. OP-TEE maps it as non-secure >>>>> RAM. This shared memory is used to pass information between OP-TEE OS >>>>> and OP-TEE client. About which safety check you are talking? >>>> >>>> Well, does OP-TEE validate the data read from that shared region? But it >>>> seems that you don't plan to give part of the SHM to a guest, so it might be >>>> ok. >>> OP-TEE surely validate all data from NW. Also OP-TEE is written in such way, >>> that it reads from shared memory only once, to ensure that NW will not change >>> data after validation. Mediator will do the same. >> >> What do you mean by the last bit? > Let me cite TEE Internal Core API Specification (Public Release v1.1.1): > > " > The fact that Memory References may use memory directly shared with > the client implies that the Trusted Application needs to be especially > careful when handling such data: Even if the client is not allowed to > access the shared memory buffer during an operation on this buffer, > the Trusted OS usually cannot enforce this restriction. A > badly-designed or rogue client may well change the content of the > shared memory buffer at any time, even between two consecutive memory > accesses by the Trusted Application. This means that the Trusted > Application needs to be carefully written to avoid any security > problem if this happens. If values in the buffer are security > critical, the Trusted Application SHOULD always read data only once > from a shared buffer and then validate it. It MUST NOT assume that > data written to the buffer can be read unchanged later on. > " > > This requirement is for Trusted Applications, but it also true for > TEE OS as a whole and also for TEE mediators as well. I just wanted > to say, that I plan to write mediator in accordance to this. It makes sense. Thank you for the explanation. > >>> >>>> Also how OP-TEE will map this region? Cacheable...? >>> Yes, cacheable, PR, PW, non-secure. >>> >>>>> >>>>>> >>>>>>> + if ( rc < 0 ) >>>>>>> + { >>>>>>> + gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); >>>>>> >>>>>> gprintk already dump the domid. So no need to say Dom0. >>>>> I just wanted to emphasis that we mappaed memory for Dom0. Will remove. >>>> >>>> gprintk will printk d0. So there are no point to say it a second time... >>>>> >>>>>>> + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); >>>>>>> + } >>>>>>> + >>>>>>> + return true; >>>>>>> +} >>>>>>> + >>>>>>> +static bool handle_exchange_capabilities(struct cpu_user_regs *regs) >>>>>>> +{ >>>>>>> + forward_call(regs); >>>>>>> + >>>>>>> + printk("handle_exchange_capabilities\n"); >>>>>> >>>>>> Same here, no plain prink. >>>>> Sorry, this is another debug print. Missed it when formatted patches. >>>>> >>>>>>> + /* Return error back to the guest */ >>>>>>> + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>>>>>> + return true; >>>>>>> + >>>>>>> + /* Don't allow guests to work without dynamic SHM */ >>>>>> >>>>>> Hmmm? But you don't support guests today. So why are you checking that? >>>>> This is a RFC. Will remove this parts of the code in a proper patch series. >>>>> >>>>> I just wanted to ensure that community is okay with proposed approach and >>>>> to show how minimalistic mediator can look. >>>> I don't think this is true. You only show how easy it is to let Dom0 >>>> accessing TEE. And as I said in the cover letter, this is not the >>>> controversial part. >>> Actually I wanted to show approach when mediator resides right in xen. >>> I got valuable input from you. Now I see that I must completely rework the >>> first patch. And, probably, show more comprehensive support from OP-TEE side. >>> >>>> The more controversial one is the guest support that you completely left >>>> aside. I believe this part will not be as minimalistic as you think because >>>> you need to translate buffer address and prevent those buffers to disappear >>>> under your feet. >>> Yes. I plan to copy all buffers where IPAs presented to another place, >>> so DomU will not be able to see PAs during translation. And I plan to >>> pin all DomU pages with a data. Also I'll read from guest pages only >>> once. I think, this will be enough. >>> >>>> There are probably other problem to fix... >>> Probably yes... >>> >>> I think, I'll focus on OP-TEE side right now and come back when there will >>> be more more to show. >> >> To clarify my view. I am not against a temporary support of OP-TEE for the >> hardware domain in Xen. But it does not mean I would be ready to see the a >> full OP-TEE support for guests in Xen. > Hm. What did you mean in last sentence? Our (here, at EPAM) target is full > virtualization support for OP-TEE. If you don't want to see it in Xen, > then what another ways we have? Sorry it was not clear enough. I meant that whilst I am happy to see OP-TEE support for the hardware domain in the hypervisor, we still need to discuss on the approach for guests. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-19 16:12 ` Julien Grall @ 2017-10-19 16:37 ` Volodymyr Babchuk 2017-10-19 16:52 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-19 16:37 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel On Thu, Oct 19, 2017 at 05:12:17PM +0100, Julien Grall wrote: Hi Julien, > >>>>>>>+ if ( rc < 0 ) > >>>>>>>+ { > >>>>>>>+ gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); > >>>>>> > >>>>>>gprintk already dump the domid. So no need to say Dom0. > >>>>>I just wanted to emphasis that we mappaed memory for Dom0. Will remove. > >>>> > >>>>gprintk will printk d0. So there are no point to say it a second time... > >>>>> > >>>>>>>+ set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); > >>>>>>>+ } > >>>>>>>+ > >>>>>>>+ return true; > >>>>>>>+} > >>>>>>>+ > >>>>>>>+static bool handle_exchange_capabilities(struct cpu_user_regs *regs) > >>>>>>>+{ > >>>>>>>+ forward_call(regs); > >>>>>>>+ > >>>>>>>+ printk("handle_exchange_capabilities\n"); > >>>>>> > >>>>>>Same here, no plain prink. > >>>>>Sorry, this is another debug print. Missed it when formatted patches. > >>>>> > >>>>>>>+ /* Return error back to the guest */ > >>>>>>>+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) > >>>>>>>+ return true; > >>>>>>>+ > >>>>>>>+ /* Don't allow guests to work without dynamic SHM */ > >>>>>> > >>>>>>Hmmm? But you don't support guests today. So why are you checking that? > >>>>>This is a RFC. Will remove this parts of the code in a proper patch series. > >>>>> > >>>>>I just wanted to ensure that community is okay with proposed approach and > >>>>>to show how minimalistic mediator can look. > >>>>I don't think this is true. You only show how easy it is to let Dom0 > >>>>accessing TEE. And as I said in the cover letter, this is not the > >>>>controversial part. > >>>Actually I wanted to show approach when mediator resides right in xen. > >>>I got valuable input from you. Now I see that I must completely rework the > >>>first patch. And, probably, show more comprehensive support from OP-TEE side. > >>> > >>>>The more controversial one is the guest support that you completely left > >>>>aside. I believe this part will not be as minimalistic as you think because > >>>>you need to translate buffer address and prevent those buffers to disappear > >>>>under your feet. > >>>Yes. I plan to copy all buffers where IPAs presented to another place, > >>>so DomU will not be able to see PAs during translation. And I plan to > >>>pin all DomU pages with a data. Also I'll read from guest pages only > >>>once. I think, this will be enough. > >>> > >>>>There are probably other problem to fix... > >>>Probably yes... > >>> > >>>I think, I'll focus on OP-TEE side right now and come back when there will > >>>be more more to show. > >> > >>To clarify my view. I am not against a temporary support of OP-TEE for the > >>hardware domain in Xen. But it does not mean I would be ready to see the a > >>full OP-TEE support for guests in Xen. > >Hm. What did you mean in last sentence? Our (here, at EPAM) target is full > >virtualization support for OP-TEE. If you don't want to see it in Xen, > >then what another ways we have? > > Sorry it was not clear enough. I meant that whilst I am happy to see OP-TEE > support for the hardware domain in the hypervisor, we still need to discuss > on the approach for guests. Excuse me, I still didn't get it. You imply that we need some completely different approach for guests? Or I can stick with current approach, just add more restrictions? Under "current approach" I mostly mean "handle SMCs to TEE at EL2" as opposed to "handle them in stubdom". Half patches of this RFC should be severely reworked anyways. WBR, Volodymyr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator 2017-10-19 16:37 ` Volodymyr Babchuk @ 2017-10-19 16:52 ` Julien Grall 0 siblings, 0 replies; 44+ messages in thread From: Julien Grall @ 2017-10-19 16:52 UTC (permalink / raw) To: Volodymyr Babchuk Cc: Julien Grall, Stefano Stabellini, Jens Wiklander, xen-devel Hi, On 19/10/17 17:37, Volodymyr Babchuk wrote: > On Thu, Oct 19, 2017 at 05:12:17PM +0100, Julien Grall wrote: > > Hi Julien, > >>>>>>>>> + if ( rc < 0 ) >>>>>>>>> + { >>>>>>>>> + gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc); >>>>>>>> >>>>>>>> gprintk already dump the domid. So no need to say Dom0. >>>>>>> I just wanted to emphasis that we mappaed memory for Dom0. Will remove. >>>>>> >>>>>> gprintk will printk d0. So there are no point to say it a second time... >>>>>>> >>>>>>>>> + set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL); >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + return true; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> +static bool handle_exchange_capabilities(struct cpu_user_regs *regs) >>>>>>>>> +{ >>>>>>>>> + forward_call(regs); >>>>>>>>> + >>>>>>>>> + printk("handle_exchange_capabilities\n"); >>>>>>>> >>>>>>>> Same here, no plain prink. >>>>>>> Sorry, this is another debug print. Missed it when formatted patches. >>>>>>> >>>>>>>>> + /* Return error back to the guest */ >>>>>>>>> + if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK) >>>>>>>>> + return true; >>>>>>>>> + >>>>>>>>> + /* Don't allow guests to work without dynamic SHM */ >>>>>>>> >>>>>>>> Hmmm? But you don't support guests today. So why are you checking that? >>>>>>> This is a RFC. Will remove this parts of the code in a proper patch series. >>>>>>> >>>>>>> I just wanted to ensure that community is okay with proposed approach and >>>>>>> to show how minimalistic mediator can look. >>>>>> I don't think this is true. You only show how easy it is to let Dom0 >>>>>> accessing TEE. And as I said in the cover letter, this is not the >>>>>> controversial part. >>>>> Actually I wanted to show approach when mediator resides right in xen. >>>>> I got valuable input from you. Now I see that I must completely rework the >>>>> first patch. And, probably, show more comprehensive support from OP-TEE side. >>>>> >>>>>> The more controversial one is the guest support that you completely left >>>>>> aside. I believe this part will not be as minimalistic as you think because >>>>>> you need to translate buffer address and prevent those buffers to disappear >>>>>> under your feet. >>>>> Yes. I plan to copy all buffers where IPAs presented to another place, >>>>> so DomU will not be able to see PAs during translation. And I plan to >>>>> pin all DomU pages with a data. Also I'll read from guest pages only >>>>> once. I think, this will be enough. >>>>> >>>>>> There are probably other problem to fix... >>>>> Probably yes... >>>>> >>>>> I think, I'll focus on OP-TEE side right now and come back when there will >>>>> be more more to show. >>>> >>>> To clarify my view. I am not against a temporary support of OP-TEE for the >>>> hardware domain in Xen. But it does not mean I would be ready to see the a >>>> full OP-TEE support for guests in Xen. >>> Hm. What did you mean in last sentence? Our (here, at EPAM) target is full >>> virtualization support for OP-TEE. If you don't want to see it in Xen, >>> then what another ways we have? >> >> Sorry it was not clear enough. I meant that whilst I am happy to see OP-TEE >> support for the hardware domain in the hypervisor, we still need to discuss >> on the approach for guests. > Excuse me, I still didn't get it. You imply that we need some > completely different approach for guests? Or I can stick with current > approach, just add more restrictions? > > Under "current approach" I mostly mean "handle SMCs to TEE at EL2" as > opposed to "handle them in stubdom". Half patches of this RFC should > be severely reworked anyways. Let me answer on your cover letter. That would be easier to draw a decision with your last e-mail. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-11 19:01 [RFC 0/4] TEE mediator framework + OP-TEE mediator Volodymyr Babchuk ` (3 preceding siblings ...) 2017-10-11 19:01 ` [RFC 4/4] arm: tee: add basic OP-TEE mediator Volodymyr Babchuk @ 2017-10-16 12:00 ` Julien Grall 2017-10-17 15:59 ` Volodymyr Babchuk 4 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-16 12:00 UTC (permalink / raw) To: Volodymyr Babchuk, Stefano Stabellini, xen-devel On 11/10/17 20:01, Volodymyr Babchuk wrote: > Hello all, Hi Volodymyr, > > I want to present TEE mediator, that was discussed earlier ([1]). > > I selected design with built-in mediators. This is easiest way, > it removes many questions, it is easy to implement and maintain > (at least I hope so). Well, it may close the technical questions but still leave the security impact unanswered. I would have appreciated a summary of each approach and explain the pros/cons. This would help to understand that maybe it is an easy way but also still secure... To be clear, this series don't look controversial at least for OP-TEE. What I am more concerned is about DomU supports. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-16 12:00 ` [RFC 0/4] TEE mediator framework + " Julien Grall @ 2017-10-17 15:59 ` Volodymyr Babchuk 2017-10-20 13:11 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-17 15:59 UTC (permalink / raw) To: Julien Grall; +Cc: Stefano Stabellini, xen-devel On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: > > > On 11/10/17 20:01, Volodymyr Babchuk wrote: > >Hello all, > > Hi Volodymyr, Hi Julien > > > > >I want to present TEE mediator, that was discussed earlier ([1]). > > > >I selected design with built-in mediators. This is easiest way, > >it removes many questions, it is easy to implement and maintain > >(at least I hope so). > > Well, it may close the technical questions but still leave the security > impact unanswered. I would have appreciated a summary of each approach and > explain the pros/cons. This is the most secure way also. In terms of trust between guests and Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about "security", my first thoughts are "Can TEE OS trust to XEN as a mediator? Can TEE client trust to XEN as a mediator?". And with current approach answer is "yes, they can, especially if XEN is a part of a chain of trust". But you probably wanted to ask "Can guest compromise whole system by using TEE mediator or TEE OS?". This is an interesting question. First let's discuss requirements for a TEE mediator. So, mediator should be able to: * Receive request to handle trapped SMC. This request should include user registers + some information about guest (at least domain id). * Pin/unpin domain memory pages. * Map domain memory pages into own address space with RW access. * Issue real SMC to a TEE. * Receive information about guest creation and destruction. * (Probably) inject IRQs into a domain (this can be not a requester domain, but some other domain, that also called to TEE). This is a minimal list of requirements. I think, this should be enough to implement mediator for OP-TEE. But I can't say for sure for other TEEs. Let's consider possible approaches: 1. Mediator right in XEN, works at EL2. Pros: * Mediator can use all XEN APIs * As mediator resides in XEN, it can be checked together with XEN for a validity (trusted boot). * Mediator is initialized before Dom0. Dom0 can work with a TEE. * No extra context switches, no special ABI between XEN and mediator. Cons: * Because it lives in EL2, it can compromise whole hypervisor, if there is a security bug in mediator code. * No support for closed source TEEs. 2. Mediator in a stubdomain. Works at EL1. Pros: * Mediator is isolated from hypervisor (but it still can do potentially dangerous things like mapping domain memory or pining pages). * One can legally create and use mediator for a closed-source TEE. Cons: * Overhead in XEN<->Mediator communication. * XEN needs to be modified to boot mediator domain before Dom0. * Some extra entity required to check validity of a mediator. 3. Mediator in an EL0 app. The same pros and cons as for mediator in a stubdomain + extra code for EL0 apps, which is needed to be supported and maintained. Now, back to security questions. There are two possible attacks: attack at XEN and attack at TEE itself. If your TEE is vulnerable, then your whole system is compromised anyways. AFAIK, this approach was used to hack Samsung phones. Some flaw in Qualcom's TZ implementation. If your TEE mediator is vulnerable, then your hypervisor and all guests are compromised. Yes TEE mediator increases attack surface, but the same does any other XEN<->Guest interface. TEE mediators are expected to be simple and straightforward, without complex logic. So, I think that they are not more dangerous than vGIC driver or PL011 emulator. And yes, it seems obvious, but I want to say this explicitly: generic TEE mediator framework should and will use XSM to control which domain can work with TEE. So, if you don't trust your guest - don't let it to call TEE at all. This feature is not implemented in this RFC only because currently only Dom0 calls are supported. > This would help to understand that maybe it is an easy way but also still > secure... In previous discussion we considered only two variants: in XEN or outside XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. Such stubdomain will need access to all guests memory. If you managed to gain control on mediator stubdomain, you can do anything you want with all guests. > To be clear, this series don't look controversial at least for OP-TEE. What > I am more concerned is about DomU supports. Your concern is that rogue DomU can compromise whole system, right? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-17 15:59 ` Volodymyr Babchuk @ 2017-10-20 13:11 ` Julien Grall 2017-10-20 16:57 ` Tamas K Lengyel 2017-10-20 17:37 ` Volodymyr Babchuk 0 siblings, 2 replies; 44+ messages in thread From: Julien Grall @ 2017-10-20 13:11 UTC (permalink / raw) To: Volodymyr Babchuk; +Cc: nd, Stefano Stabellini, xen-devel Hi Volodymyr, On 17/10/17 16:59, Volodymyr Babchuk wrote: > On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: >> >> >> On 11/10/17 20:01, Volodymyr Babchuk wrote: >>> Hello all, >> >> Hi Volodymyr, > Hi Julien >> >>> >>> I want to present TEE mediator, that was discussed earlier ([1]). >>> >>> I selected design with built-in mediators. This is easiest way, >>> it removes many questions, it is easy to implement and maintain >>> (at least I hope so). >> >> Well, it may close the technical questions but still leave the security >> impact unanswered. I would have appreciated a summary of each approach and >> explain the pros/cons. > This is the most secure way also. In terms of trust between guests and > Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about > "security", my first thoughts are "Can TEE OS trust to XEN as a > mediator? Can TEE client trust to XEN as a mediator?". And with > current approach answer is "yes, they can, especially if XEN is a part > of a chain of trust". > > But you probably wanted to ask "Can guest compromise whole system by > using TEE mediator or TEE OS?". This is an interesting question. > First let's discuss requirements for a TEE mediator. So, mediator > should be able to: > > * Receive request to handle trapped SMC. This request should include > user registers + some information about guest (at least domain id). > * Pin/unpin domain memory pages. > * Map domain memory pages into own address space with RW access. > * Issue real SMC to a TEE. > * Receive information about guest creation and destruction. > * (Probably) inject IRQs into a domain (this can be not a requester domain, > but some other domain, that also called to TEE). > > This is a minimal list of requirements. I think, this should be enough to > implement mediator for OP-TEE. But I can't say for sure for other TEEs. > > Let's consider possible approaches: > > 1. Mediator right in XEN, works at EL2. > Pros: > * Mediator can use all XEN APIs > * As mediator resides in XEN, it can be checked together with XEN > for a validity (trusted boot). > * Mediator is initialized before Dom0. Dom0 can work with a TEE. > * No extra context switches, no special ABI between XEN and mediator. > > Cons: > * Because it lives in EL2, it can compromise whole hypervisor, > if there is a security bug in mediator code. > * No support for closed source TEEs. Another cons is you assume TEE API is fully stable and will not change. Imagine a new function is added, or a vendor decided to hence with a new set of API. How will you know Xen is safe to use it? If it is not safe, this means you have a whitelist solution and therefore tie Xen to a specific OP-TEE version. So if you need to use a new function you would need to upgrade Xen making the code of using new version potentially high. Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you impose anyone wanted to modify OP-TEE for their own purpose can make a closed version of the TEE. But if you need to introspect/whitelist call, you impose the vendor to expose their API. > > 2. Mediator in a stubdomain. Works at EL1. > Pros: > * Mediator is isolated from hypervisor (but it still can do potentially > dangerous things like mapping domain memory or pining pages). > * One can legally create and use mediator for a closed-source TEE. * Easier to upgrade to a new version of OP-TEE. > > Cons: > * Overhead in XEN<->Mediator communication. > * XEN needs to be modified to boot mediator domain before Dom0. Is it a really cons? In the past, we had discussion to allow Xen creating multiple domain, avoiding the overhead of Dom0. This could also benefits here. > * Some extra entity required to check validity of a mediator. > > 3. Mediator in an EL0 app. > The same pros and cons as for mediator in a stubdomain + extra code for EL0 > apps, which is needed to be supported and maintained. > > Now, back to security questions. There are two possible attacks: > attack at XEN and attack at TEE itself. > > If your TEE is vulnerable, then your whole system is compromised anyways. > AFAIK, this approach was used to hack Samsung phones. Some flaw in Qualcom's > TZ implementation. > > If your TEE mediator is vulnerable, then your hypervisor and all guests are > compromised. Yes TEE mediator increases attack surface, but the same does > any other XEN<->Guest interface. TEE mediators are expected to be simple > and straightforward, without complex logic. So, I think that they are not > more dangerous than vGIC driver or PL011 emulator. To be honest when I read the list that a mediator should be able to do, I don't think it is possible to say it will not have complex logic. For instance, for memory pinning. You need to know the buffers which likely means introspection of the calls if there are nested buffers. This implies that you may tie into a specific version of TEE for a specific version of Xen. So how do you expect OP-TEE evolving with Xen support? For example, if there is a new function do you expect to work on previous version of Xen? Or shall it wait the next release? > > And yes, it seems obvious, but I want to say this explicitly: generic > TEE mediator framework should and will use XSM to control which domain > can work with TEE. So, if you don't trust your guest - don't let it > to call TEE at all. Correct me if I am wrong. TEE could be used by Android guest which likely run the user apps... right? So are you saying you fully trust that guest and obviously the user installing rogue app? > This feature is not implemented in this RFC only because > currently only Dom0 calls are supported. > >> This would help to understand that maybe it is an easy way but also still >> secure... > In previous discussion we considered only two variants: in XEN or outside > XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. > Such stubdomain will need access to all guests memory. If you managed to > gain control on mediator stubdomain, you can do anything you want with all > guests. That's slightly untrue. The stubdomain will only be able to mess with domains using TEE. > >> To be clear, this series don't look controversial at least for OP-TEE. What >> I am more concerned is about DomU supports. > Your concern is that rogue DomU can compromise whole system, right? Yes. You seem to assume that DomU using TEE will always be trusted, I think this is the wrong approach if the use is able to interact directly with those guests. See above. Cheers, -- Julien Grall -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-20 13:11 ` Julien Grall @ 2017-10-20 16:57 ` Tamas K Lengyel 2017-10-20 17:46 ` Volodymyr Babchuk 2017-10-20 17:37 ` Volodymyr Babchuk 1 sibling, 1 reply; 44+ messages in thread From: Tamas K Lengyel @ 2017-10-20 16:57 UTC (permalink / raw) To: Julien Grall; +Cc: nd, Volodymyr Babchuk, Stefano Stabellini, Xen-devel >> In previous discussion we considered only two variants: in XEN or outside >> XEN. Stubdomain approach looks more secure, but I'm not sure that it is >> true. >> Such stubdomain will need access to all guests memory. If you managed to >> gain control on mediator stubdomain, you can do anything you want with all >> guests. > > > That's slightly untrue. The stubdomain will only be able to mess with > domains using TEE. Would it be feasible to have multiple TEE stubdoms providing the interface for select domUs (with XSM)? IMHO that would provide the greatest disaggregation and thus the most security. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-20 16:57 ` Tamas K Lengyel @ 2017-10-20 17:46 ` Volodymyr Babchuk 0 siblings, 0 replies; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-20 17:46 UTC (permalink / raw) To: Tamas K Lengyel, Julien Grall; +Cc: nd, Stefano Stabellini, Xen-devel On 20.10.17 19:57, Tamas K Lengyel wrote: Hello Tamas, >>> In previous discussion we considered only two variants: in XEN or outside >>> XEN. Stubdomain approach looks more secure, but I'm not sure that it is >>> true. >>> Such stubdomain will need access to all guests memory. If you managed to >>> gain control on mediator stubdomain, you can do anything you want with all >>> guests. >> >> >> That's slightly untrue. The stubdomain will only be able to mess with >> domains using TEE. > > Would it be feasible to have multiple TEE stubdoms providing the > interface for select domUs (with XSM)? IMHO that would provide the > greatest disaggregation and thus the most security. If we wanted to provide every DomU with own instance of virtual TEE - that would work. But we want to allow DomUs to work with real a TEE. Thus we need TEE mediator, and mediator will need to have a shared state. So we can't split it among multiple stubdoms. WBR Volodymyr Babchuk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-20 13:11 ` Julien Grall 2017-10-20 16:57 ` Tamas K Lengyel @ 2017-10-20 17:37 ` Volodymyr Babchuk 2017-10-23 16:59 ` Julien Grall 1 sibling, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-20 17:37 UTC (permalink / raw) To: Julien Grall; +Cc: nd, Stefano Stabellini, xen-devel On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, > On 17/10/17 16:59, Volodymyr Babchuk wrote: > >On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: > >> > >> > >>On 11/10/17 20:01, Volodymyr Babchuk wrote: > >>>Hello all, > >> > >>Hi Volodymyr, > >Hi Julien > >> > >>> > >>>I want to present TEE mediator, that was discussed earlier ([1]). > >>> > >>>I selected design with built-in mediators. This is easiest way, > >>>it removes many questions, it is easy to implement and maintain > >>>(at least I hope so). > >> > >>Well, it may close the technical questions but still leave the security > >>impact unanswered. I would have appreciated a summary of each approach and > >>explain the pros/cons. > >This is the most secure way also. In terms of trust between guests and > >Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about > >"security", my first thoughts are "Can TEE OS trust to XEN as a > >mediator? Can TEE client trust to XEN as a mediator?". And with > >current approach answer is "yes, they can, especially if XEN is a part > >of a chain of trust". > > > >But you probably wanted to ask "Can guest compromise whole system by > >using TEE mediator or TEE OS?". This is an interesting question. > >First let's discuss requirements for a TEE mediator. So, mediator > >should be able to: > > > > * Receive request to handle trapped SMC. This request should include > > user registers + some information about guest (at least domain id). > > * Pin/unpin domain memory pages. > > * Map domain memory pages into own address space with RW access. > > * Issue real SMC to a TEE. > > * Receive information about guest creation and destruction. > > * (Probably) inject IRQs into a domain (this can be not a requester domain, > > but some other domain, that also called to TEE). > > > >This is a minimal list of requirements. I think, this should be enough to > >implement mediator for OP-TEE. But I can't say for sure for other TEEs. > > > >Let's consider possible approaches: > > > >1. Mediator right in XEN, works at EL2. > > Pros: > > * Mediator can use all XEN APIs > > * As mediator resides in XEN, it can be checked together with XEN > > for a validity (trusted boot). > > * Mediator is initialized before Dom0. Dom0 can work with a TEE. > > * No extra context switches, no special ABI between XEN and mediator. > > > > Cons: > > * Because it lives in EL2, it can compromise whole hypervisor, > > if there is a security bug in mediator code. > > * No support for closed source TEEs. > > Another cons is you assume TEE API is fully stable and will not change. > Imagine a new function is added, or a vendor decided to hence with a new set > of API. How will you know Xen is safe to use it? With whitelisting, as you correctly suggested below. XEN will process only know requests. Anything that looks unfimiliar should be rejected. > If it is not safe, this means you have a whitelist solution and therefore > tie Xen to a specific OP-TEE version. So if you need to use a new function > you would need to upgrade Xen making the code of using new version > potentially high. Yes, any ABI change between OP-TEE and its clients will require mediator upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, which is known to XEN. > Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you > impose anyone wanted to modify OP-TEE for their own purpose can make a > closed version of the TEE. But if you need to introspect/whitelist call, you > impose the vendor to expose their API. Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. If vendor modifies interface between OP-TEE and Linux, they anyways obligued to expose API. > > > >2. Mediator in a stubdomain. Works at EL1. > > Pros: > > * Mediator is isolated from hypervisor (but it still can do potentially > > dangerous things like mapping domain memory or pining pages). > > * One can legally create and use mediator for a closed-source TEE. > > * Easier to upgrade to a new version of OP-TEE. Yes, this is true. But what about interface between XEN and mediator? This is a new entity that should be maintained. Will I abe able to use new XEN with old mediator? Or new mediator with old XEN? > >> Cons: > > * Overhead in XEN<->Mediator communication. > > * XEN needs to be modified to boot mediator domain before Dom0. > > Is it a really cons? In the past, we had discussion to allow Xen creating > multiple domain, avoiding the overhead of Dom0. This could also benefits > here. As I understand, this is a significant change in XEN. What are the chances, that community will accept this change? As I can see, immediate benefit of this is only TEE mediator support. Looks like no one except us interested in this topic. BTW, I checked "Xen on ARM: create multiple guests from device tree" at [1]. This is close, to what we need, but not exactly. You see, TEE mediator should be created *before* Dom0. So actually TEE mediator will receive domid 0. I suspect that this only change will break many things. > > * Some extra entity required to check validity of a mediator. > > > >3. Mediator in an EL0 app. > > The same pros and cons as for mediator in a stubdomain + extra code for EL0 > > apps, which is needed to be supported and maintained. > > > >Now, back to security questions. There are two possible attacks: > >attack at XEN and attack at TEE itself. > > > >If your TEE is vulnerable, then your whole system is compromised anyways. > >AFAIK, this approach was used to hack Samsung phones. Some flaw in Qualcom's > >TZ implementation. > > > >If your TEE mediator is vulnerable, then your hypervisor and all guests are > >compromised. Yes TEE mediator increases attack surface, but the same does > >any other XEN<->Guest interface. TEE mediators are expected to be simple > >and straightforward, without complex logic. So, I think that they are not > >more dangerous than vGIC driver or PL011 emulator. > > To be honest when I read the list that a mediator should be able to do, I > don't think it is possible to say it will not have complex logic. Maybe we have different opinion on what is "complex" :) This is pretty straightforward: map memory, cast it to comand buffer structure, examine types of parameters. > For instance, for memory pinning. You need to know the buffers which likely > means introspection of the calls if there are nested buffers. > > This implies that you may tie into a specific version of TEE for a specific > version of Xen. As I said, OP-TEE maintains backward-compatible interface. Can't say for other TEEs, though. > So how do you expect OP-TEE evolving with Xen support? For example, if there > is a new function do you expect to work on previous version of Xen? Or shall > it wait the next release? OP-TEE interface does not change much from version to version. I know about three of that changes. They all was upstreamed in OP-TEE OS, but only one is being upstreamed into optee client right now. So, vanilla Linux right now support only the basic OP-TEE interface. Custom builds can work with all extensions. I don't think, that is big deal if XEN mediator will lag one version behind, relative to OP-TEE. > > > >And yes, it seems obvious, but I want to say this explicitly: generic > >TEE mediator framework should and will use XSM to control which domain > >can work with TEE. So, if you don't trust your guest - don't let it > >to call TEE at all. > > Correct me if I am wrong. TEE could be used by Android guest which likely > run the user apps... right? So are you saying you fully trust that guest and > obviously the user installing rogue app? I don't think that app downloaded from Play Marget can access OP-TEE directly. OP-TEE can be used by Android itself as a key storage or to access to a SE, for example. But 3rd app that issues TEE calls... I don't think so. > >This feature is not implemented in this RFC only because > >currently only Dom0 calls are supported. > > > >>This would help to understand that maybe it is an easy way but also still > >>secure... > >In previous discussion we considered only two variants: in XEN or outside > >XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. > >Such stubdomain will need access to all guests memory. If you managed to > >gain control on mediator stubdomain, you can do anything you want with all > >guests. > > That's slightly untrue. The stubdomain will only be able to mess with > domains using TEE. Yes, this is more strict. Then either you are not allowing your privileged domain to use TEE, or your system may be compromised anyways. > > > >>To be clear, this series don't look controversial at least for OP-TEE. What > >>I am more concerned is about DomU supports. > >Your concern is that rogue DomU can compromise whole system, right? > > Yes. You seem to assume that DomU using TEE will always be trusted, I think > this is the wrong approach if the use is able to interact directly with > those guests. See above. No, I am not assuming that DomU that calls TEE should be trusted. Why do you think so? It should be able to use TEE services, but this does not mean that XEN should trust it. Even now, XEN processes requests from DomUs without trusting them. Why do you think, that TEE mediator usage will differ? Look, I generally not against idea of TEE mediator in stubdoms. But this approach require many changes in existing XEN code: 1. Load domains before Dom0. 2. Add special API for mediator. Or alter existing ones. You can't use existing APIs as it, because you need to enforce stricter XSM rules on them. 3. Changes in scheduling to allow TEE mediator use credits/slices of calling guest. 4. Support boilerplate code in stubdom. You know, you can't simply write mediator in stubdom. You need a kernel. You need to maintain it. This is a lot of a work. It requires changes in generic parts of XEN. I fear it will be very hard to upstream such changes, because no one sees an immediate value in them. How do you think, what are my chances to upstream this? Approach in this RFC is much simpler. Few hooks in arch code + additional subsystem, which can be easily turned off. [1] https://wiki.xenproject.org/wiki/Outreach_Program_Projects WBR, Volodymyr Babchuk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-20 17:37 ` Volodymyr Babchuk @ 2017-10-23 16:59 ` Julien Grall 2017-10-23 20:11 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-23 16:59 UTC (permalink / raw) To: Volodymyr Babchuk, Julien Grall; +Cc: nd, Stefano Stabellini, xen-devel Hi Volodymyr, Let me begin the e-mail with I am not totally adversed to putting the TEE mediator in Xen. At the moment, I am trying to understand the whole picture. On 20/10/17 18:37, Volodymyr Babchuk wrote: > On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote: >> On 17/10/17 16:59, Volodymyr Babchuk wrote: >>> On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: >>>> On 11/10/17 20:01, Volodymyr Babchuk wrote: >>>>> I want to present TEE mediator, that was discussed earlier ([1]). >>>>> >>>>> I selected design with built-in mediators. This is easiest way, >>>>> it removes many questions, it is easy to implement and maintain >>>>> (at least I hope so). >>>> >>>> Well, it may close the technical questions but still leave the security >>>> impact unanswered. I would have appreciated a summary of each approach and >>>> explain the pros/cons. >>> This is the most secure way also. In terms of trust between guests and >>> Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about >>> "security", my first thoughts are "Can TEE OS trust to XEN as a >>> mediator? Can TEE client trust to XEN as a mediator?". And with >>> current approach answer is "yes, they can, especially if XEN is a part >>> of a chain of trust". >>> >>> But you probably wanted to ask "Can guest compromise whole system by >>> using TEE mediator or TEE OS?". This is an interesting question. >>> First let's discuss requirements for a TEE mediator. So, mediator >>> should be able to: >>> >>> * Receive request to handle trapped SMC. This request should include >>> user registers + some information about guest (at least domain id). >>> * Pin/unpin domain memory pages. >>> * Map domain memory pages into own address space with RW access. >>> * Issue real SMC to a TEE. >>> * Receive information about guest creation and destruction. >>> * (Probably) inject IRQs into a domain (this can be not a requester domain, >>> but some other domain, that also called to TEE). >>> >>> This is a minimal list of requirements. I think, this should be enough to >>> implement mediator for OP-TEE. But I can't say for sure for other TEEs. >>> >>> Let's consider possible approaches: >>> >>> 1. Mediator right in XEN, works at EL2. >>> Pros: >>> * Mediator can use all XEN APIs >>> * As mediator resides in XEN, it can be checked together with XEN >>> for a validity (trusted boot). >>> * Mediator is initialized before Dom0. Dom0 can work with a TEE. >>> * No extra context switches, no special ABI between XEN and mediator. >>> >>> Cons: >>> * Because it lives in EL2, it can compromise whole hypervisor, >>> if there is a security bug in mediator code. >>> * No support for closed source TEEs. >> >> Another cons is you assume TEE API is fully stable and will not change. >> Imagine a new function is added, or a vendor decided to hence with a new set >> of API. How will you know Xen is safe to use it? > With whitelisting, as you correctly suggested below. XEN will process > only know requests. Anything that looks unfimiliar should be rejected. Let's imagine the guest is running on a platform with a newer version of TEE. This guest will probe the version of OP-TEE and knows the new function is present. If as you said Xen is using a whitelist, this means the hypervisor will return unimplemented. How do you expect the guest to behave in that case? Note that I think a whitelist is a good idea, but I think we need to think a bit more about the implication. > >> If it is not safe, this means you have a whitelist solution and therefore >> tie Xen to a specific OP-TEE version. So if you need to use a new function >> you would need to upgrade Xen making the code of using new version >> potentially high. > Yes, any ABI change between OP-TEE and its clients will require mediator > upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll > install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, > which is known to XEN. > >> Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you >> impose anyone wanted to modify OP-TEE for their own purpose can make a >> closed version of the TEE. But if you need to introspect/whitelist call, you >> impose the vendor to expose their API. > Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. > If vendor modifies interface between OP-TEE and Linux, they anyways obligued > to expose API. Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. My understanding is the OP-TEE will provide a generic way to access different Trusted Application. While OP-TEE API may be generic, the TA API is custom. AFAICT the latter is not part of Linux driver. So here my questions: 1) Are you planning allow all the guests to access every Trusted Applications? 2) Will you ever need to introspect those messages? >>> >>> 2. Mediator in a stubdomain. Works at EL1. >>> Pros: >>> * Mediator is isolated from hypervisor (but it still can do potentially >>> dangerous things like mapping domain memory or pining pages). >>> * One can legally create and use mediator for a closed-source TEE. >> >> * Easier to upgrade to a new version of OP-TEE. > Yes, this is true. But what about interface between XEN and mediator? > This is a new entity that should be maintained. Will I abe able to use > new XEN with old mediator? Or new mediator with old XEN? Why would you need to specific interface for the mediator? (see more below) > >>>> Cons: >>> * Overhead in XEN<->Mediator communication. >>> * XEN needs to be modified to boot mediator domain before Dom0. >> >> Is it a really cons? In the past, we had discussion to allow Xen creating >> multiple domain, avoiding the overhead of Dom0. This could also benefits >> here. > As I understand, this is a significant change in XEN. What are the chances, > that community will accept this change? As I can see, immediate benefit > of this is only TEE mediator support. Looks like no one except us > interested in this topic. The GSOC project was not added because of TEE mediator. We had companies showing interest to start multiple domains at the same time. This would significantly shrink down the boot time of the whole platform. > > BTW, I checked "Xen on ARM: create multiple guests from device > tree" at [1]. This is close, to what we need, but not exactly. You see, > TEE mediator should be created *before* Dom0. So actually TEE mediator > will receive domid 0. I suspect that this only change will break > many things. Can you please give example? Technically none of the hypervisor, Linux and the toolstack should rely on dom0 to be domid 0. AFAIK, the hypervisor and Linux are free of them. It might be possible to have few hardcoded in the toolstack, but they should really disappear. However, I can't see why you require the mediator to use domid 0. You could for example keep the hardware domain paused until the mediator has started. [...] > >>> >>> And yes, it seems obvious, but I want to say this explicitly: generic >>> TEE mediator framework should and will use XSM to control which domain >>> can work with TEE. So, if you don't trust your guest - don't let it >>> to call TEE at all. >> >> Correct me if I am wrong. TEE could be used by Android guest which likely >> run the user apps... right? So are you saying you fully trust that guest and >> obviously the user installing rogue app? > I don't think that app downloaded from Play Marget can access OP-TEE directly. > OP-TEE can be used by Android itself as a key storage or to access to a SE, > for example. But 3rd app that issues TEE calls... I don't think so. You didn't get my point here. That rogue app may be able to break into kernel via an exploit or have enough privilege to break the guest. Who knows what it will be able to do after... The whole point of using an hypervisor is to isolate guest from each other. So what is the isolation model with OP-TEE and the mediator? > >>> This feature is not implemented in this RFC only because >>> currently only Dom0 calls are supported. >>> >>>> This would help to understand that maybe it is an easy way but also still >>>> secure... >>> In previous discussion we considered only two variants: in XEN or outside >>> XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. >>> Such stubdomain will need access to all guests memory. If you managed to >>> gain control on mediator stubdomain, you can do anything you want with all >>> guests. >> >> That's slightly untrue. The stubdomain will only be able to mess with >> domains using TEE. > Yes, this is more strict. Then either you are not allowing your privileged > domain to use TEE, or your system may be compromised anyways. Can you give an example of privilege domain for you? Do you consider Android a privilege domain? >>> >>>> To be clear, this series don't look controversial at least for OP-TEE. What >>>> I am more concerned is about DomU supports. >>> Your concern is that rogue DomU can compromise whole system, right? >> >> Yes. You seem to assume that DomU using TEE will always be trusted, I think >> this is the wrong approach if the use is able to interact directly with >> those guests. See above. > No, I am not assuming that DomU that calls TEE should be trusted. Why do you > think so? It should be able to use TEE services, but this does not mean that > XEN should trust it. In a previous answer you said: "So, if you don't trust your guest - don't let it". For me, this clearly means you consider that DomU using TEE are trusted. So can you clarify by what you mean by trust then? > Even now, XEN processes requests from DomUs without > trusting them. Why do you think, that TEE mediator usage will differ? I guess you are comparing with vGIC and PL011? IHMO, the main difference is Xen is taking care alone of the isolation between guest. Here in the TEE case, you rely on a combination of both TEE and Xen to do the isolation. > > Look, I generally not against idea of TEE mediator in stubdoms. But this > approach require many changes in existing XEN code: > > 1. Load domains before Dom0. > > 2. Add special API for mediator. Or alter existing ones. You can't use > existing APIs as it, because you need to enforce stricter XSM rules > on them. Mind giving more explanation....? Xen has a default policy for XSM and indeed may not fit your use case. But you can write your own policy and load it. > > 3. Changes in scheduling to allow TEE mediator use credits/slices of > calling guest. > > 4. Support boilerplate code in stubdom. You know, you can't simply > write mediator in stubdom. You need a kernel. You need to > maintain it. Well, in a way or another someone will have to maintain the mediator... The kernel does not need to be specific to TEE, it could be a unikernel. And before you say again no-one in the community seem to be interested. I should remind you that Arm is working on it (see development update). > > This is a lot of a work. It requires changes in generic parts of XEN. > I fear it will be very hard to upstream such changes, because no one > sees an immediate value in them. How do you think, what are my chances > to upstream this? It is fairly annoying to see you justifying back most of this thread with "no one sees an immediate value in them". I am not the only maintainers in Xen, so effectively can't promise whether it is going to be upstreamed. But I believe the community has been very supportive so far, a lot of discussions happened (see [2]) because of the OP-TEE support. So what more do you expect from us? > > Approach in this RFC is much simpler. Few hooks in arch code + additional > subsystem, which can be easily turned off. Stefano do you have any opinion on this discussion? Regards, > > [1] https://wiki.xenproject.org/wiki/Outreach_Program_Projects [2] https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg01931.html -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-23 16:59 ` Julien Grall @ 2017-10-23 20:11 ` Volodymyr Babchuk 2017-10-23 21:26 ` Stefano Stabellini 2017-10-24 17:33 ` Julien Grall 0 siblings, 2 replies; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-23 20:11 UTC (permalink / raw) To: Julien Grall; +Cc: Julien Grall, nd, Stefano Stabellini, xen-devel On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, > Let me begin the e-mail with I am not totally adversed to putting the TEE > mediator in Xen. At the moment, I am trying to understand the whole picture. Thanks for clarification. This is really reassuring :) In my turn, I'm not totally against TEE mediators in stubdoms. I'm only concerned about required efforts. > On 20/10/17 18:37, Volodymyr Babchuk wrote: > >On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote: > >>On 17/10/17 16:59, Volodymyr Babchuk wrote: > >>>On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: > >>>>On 11/10/17 20:01, Volodymyr Babchuk wrote: > >>>>>I want to present TEE mediator, that was discussed earlier ([1]). > >>>>> > >>>>>I selected design with built-in mediators. This is easiest way, > >>>>>it removes many questions, it is easy to implement and maintain > >>>>>(at least I hope so). > >>>> > >>>>Well, it may close the technical questions but still leave the security > >>>>impact unanswered. I would have appreciated a summary of each approach and > >>>>explain the pros/cons. > >>>This is the most secure way also. In terms of trust between guests and > >>>Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about > >>>"security", my first thoughts are "Can TEE OS trust to XEN as a > >>>mediator? Can TEE client trust to XEN as a mediator?". And with > >>>current approach answer is "yes, they can, especially if XEN is a part > >>>of a chain of trust". > >>> > >>>But you probably wanted to ask "Can guest compromise whole system by > >>>using TEE mediator or TEE OS?". This is an interesting question. > >>>First let's discuss requirements for a TEE mediator. So, mediator > >>>should be able to: > >>> > >>> * Receive request to handle trapped SMC. This request should include > >>> user registers + some information about guest (at least domain id). > >>> * Pin/unpin domain memory pages. > >>> * Map domain memory pages into own address space with RW access. > >>> * Issue real SMC to a TEE. > >>> * Receive information about guest creation and destruction. > >>> * (Probably) inject IRQs into a domain (this can be not a requester domain, > >>> but some other domain, that also called to TEE). > >>> > >>>This is a minimal list of requirements. I think, this should be enough to > >>>implement mediator for OP-TEE. But I can't say for sure for other TEEs. > >>> > >>>Let's consider possible approaches: > >>> > >>>1. Mediator right in XEN, works at EL2. > >>> Pros: > >>> * Mediator can use all XEN APIs > >>> * As mediator resides in XEN, it can be checked together with XEN > >>> for a validity (trusted boot). > >>> * Mediator is initialized before Dom0. Dom0 can work with a TEE. > >>> * No extra context switches, no special ABI between XEN and mediator. > >>> > >>> Cons: > >>> * Because it lives in EL2, it can compromise whole hypervisor, > >>> if there is a security bug in mediator code. > >>> * No support for closed source TEEs. > >> > >>Another cons is you assume TEE API is fully stable and will not change. > >>Imagine a new function is added, or a vendor decided to hence with a new set > >>of API. How will you know Xen is safe to use it? > >With whitelisting, as you correctly suggested below. XEN will process > >only know requests. Anything that looks unfimiliar should be rejected. > > Let's imagine the guest is running on a platform with a newer version of > TEE. This guest will probe the version of OP-TEE and knows the new function > is present. This request will be handled mediator. At this moment, OP-TEE client does not use versions. Instead it uses capability flags. So, mediator should filter all unknown caps. This will force guest to use only supported subset of features. If, in the future, client will relly on versions (i.e. due to dramatic protocol change), mediator can either downgrade version or refuse to work at all. > If as you said Xen is using a whitelist, this means the hypervisor will > return unimplemented. > How do you expect the guest to behave in that case? As I said above, guest should downgrade to supported features subset. > Note that I think a whitelist is a good idea, but I think we need to think a > bit more about the implication. At least now OP-TEE is designed in a such way, that it is compatible in both ways. I'm sure that future OP-TEE development will be done with virtualization support in mind, so it will not break existing setups. > > > >>If it is not safe, this means you have a whitelist solution and therefore > >>tie Xen to a specific OP-TEE version. So if you need to use a new function > >>you would need to upgrade Xen making the code of using new version > >>potentially high. > >Yes, any ABI change between OP-TEE and its clients will require mediator > >upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll > >install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, > >which is known to XEN. > > > >>Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you > >>impose anyone wanted to modify OP-TEE for their own purpose can make a > >>closed version of the TEE. But if you need to introspect/whitelist call, you > >>impose the vendor to expose their API. > >Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. > >If vendor modifies interface between OP-TEE and Linux, they anyways obligued > >to expose API. > > Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. > > My understanding is the OP-TEE will provide a generic way to access > different Trusted Application. While OP-TEE API may be generic, the TA API > is custom. AFAICT the latter is not part of Linux driver. Yes, you are perfectly right there. > So here my questions: > 1) Are you planning allow all the guests to access every Trusted > Applications? This is a good question. There are two types of TAs supported in OP-TEE: real TAs (as they are described in GlobalPlatform specs) and PseudoTAs. The latter ones are statically linked right into OP-TEE kernel and execute at S-EL1 level. Real TAs are provided by client. That means that NW userspace supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA and then runs it in S-EL0. So, I'm planning to allow client to work with any real TA. I can't see real problem there. PseudoTAs can be used to access some platform-specific features, and thus it can be quite dangerous to allow anyone call them. But, generic OP-TEE includes only test and benchmark PseudoTAs, that should be disabled on production builds. So, I don't see why generic mediator should distinguish them. I think, XSM can be employed later to control which guest can access which PseudoTA. But this is not target for first version. > 2) Will you ever need to introspect those messages? No, I don't. > >>> > >>>2. Mediator in a stubdomain. Works at EL1. > >>> Pros: > >>> * Mediator is isolated from hypervisor (but it still can do potentially > >>> dangerous things like mapping domain memory or pining pages). > >>> * One can legally create and use mediator for a closed-source TEE. > >> > >> * Easier to upgrade to a new version of OP-TEE. > >Yes, this is true. But what about interface between XEN and mediator? > >This is a new entity that should be maintained. Will I abe able to use > >new XEN with old mediator? Or new mediator with old XEN? > > Why would you need to specific interface for the mediator? (see more below) At least following features in XEN control (I hope this is right term) API are missing right now: - domain creation/destruction hooks - ability to intercept only certain SMCs - way to inject IRQs to other guests Also, see more below > > > >>>> Cons: > >>> * Overhead in XEN<->Mediator communication. > >>> * XEN needs to be modified to boot mediator domain before Dom0. > >> > >>Is it a really cons? In the past, we had discussion to allow Xen creating > >>multiple domain, avoiding the overhead of Dom0. This could also benefits > >>here. > >As I understand, this is a significant change in XEN. What are the chances, > >that community will accept this change? As I can see, immediate benefit > >of this is only TEE mediator support. Looks like no one except us > >interested in this topic. > > The GSOC project was not added because of TEE mediator. We had companies > showing interest to start multiple domains at the same time. This would > significantly shrink down the boot time of the whole platform. Yes. Actually, we also interested in a faster boot. But my point was that what we need for mediator is not the same that is described in GSOC project. Functionality described at GSOC page has multiple uses. But for mediator we need something more intricate: as I said below, ability to delay boot of hwdom (and other domains). > > > >BTW, I checked "Xen on ARM: create multiple guests from device > >tree" at [1]. This is close, to what we need, but not exactly. You see, > >TEE mediator should be created *before* Dom0. So actually TEE mediator > >will receive domid 0. I suspect that this only change will break > >many things. > > Can you please give example? I'm sure that I seen checks for domid == 0 before, but now I can't find any. Probably, that was closed-source backends. So, sorry for false accusation :) > Technically none of the hypervisor, Linux and the toolstack should rely on > dom0 to be domid 0. > > AFAIK, the hypervisor and Linux are free of them. It might be possible to > have few hardcoded in the toolstack, but they should really disappear. Totaly agree there. > However, I can't see why you require the mediator to use domid 0. You could > for example keep the hardware domain paused until the mediator has started. So this will like: construct dom0, construct and run mediator domain, run dom0 by signal from DomMediator? Probably this will work. > > > >>> > >>>And yes, it seems obvious, but I want to say this explicitly: generic > >>>TEE mediator framework should and will use XSM to control which domain > >>>can work with TEE. So, if you don't trust your guest - don't let it > >>>to call TEE at all. > >> > >>Correct me if I am wrong. TEE could be used by Android guest which likely > >>run the user apps... right? So are you saying you fully trust that guest and > >>obviously the user installing rogue app? > >I don't think that app downloaded from Play Marget can access OP-TEE directly. > >OP-TEE can be used by Android itself as a key storage or to access to a SE, > >for example. But 3rd app that issues TEE calls... I don't think so. > > You didn't get my point here. That rogue app may be able to break into > kernel via an exploit or have enough privilege to break the guest. Who knows > what it will be able to do after... Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide some safer environment for sensitive data and code. This environment has well-defined interfaces and is desgined to be as safe as possible. If rogue app breaks into kernel, then it can issue any SMC which it wants. But OP-TEE does not trust to NW. Hypervisor does not trust to guests. Mediator should be written in the same way. So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is known issue. If there is a security bug in OP-TEE, it probably can overcome whole system. But this is true for any system running OP-TEE. If there is a security flaw in mediator - it can compromise either hypervisor, or DomMediator and all TEE-capable guests. Yes, this is a risk. > The whole point of using an hypervisor is to isolate guest from each other. > So what is the isolation model with OP-TEE and the mediator? OP-TEE is written to isolate TAs, resources and clients from each other. Currently there are no plans for interaction between TAs from different VMs, no resource sharing, nothing like this. What do you mean under "isolation model"? Can you give some example? > > > >>>This feature is not implemented in this RFC only because > >>>currently only Dom0 calls are supported. > >>> > >>>>This would help to understand that maybe it is an easy way but also still > >>>>secure... > >>>In previous discussion we considered only two variants: in XEN or outside > >>>XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. > >>>Such stubdomain will need access to all guests memory. If you managed to > >>>gain control on mediator stubdomain, you can do anything you want with all > >>>guests. > >> > >>That's slightly untrue. The stubdomain will only be able to mess with > >>domains using TEE. > >Yes, this is more strict. Then either you are not allowing your privileged > >domain to use TEE, or your system may be compromised anyways. > > Can you give an example of privilege domain for you? Do you consider Android > a privilege domain? In this case I used term "priviliged domain" in XEN meaning: is_privileged == 1. Android is not privileged domain, by all means. I wanted to say that you if you allow Dom0 to access TEE, then hacked DomMediator can compromise Dom0 and the hypervisor. > >>> > >>>>To be clear, this series don't look controversial at least for OP-TEE. What > >>>>I am more concerned is about DomU supports. > >>>Your concern is that rogue DomU can compromise whole system, right? > >> > >>Yes. You seem to assume that DomU using TEE will always be trusted, I think > >>this is the wrong approach if the use is able to interact directly with > >>those guests. See above. > >No, I am not assuming that DomU that calls TEE should be trusted. Why do you > >think so? It should be able to use TEE services, but this does not mean that > >XEN should trust it. > > In a previous answer you said: "So, if you don't trust your guest - don't > let it". For me, this clearly means you consider that DomU using TEE are > trusted. > > So can you clarify by what you mean by trust then? Well... In real world "trust" isn't binary option. You don't want to allow all domains to access TEE. Breached TEE user domain doesn't automatically mean that your whole system is compromised. But this certainly increases attack surface. So it is safer to give TEE access only to those domains, which really require it. You can call them sligtly more trusted, then others. > >Even now, XEN processes requests from DomUs without > >trusting them. Why do you think, that TEE mediator usage will differ? > > I guess you are comparing with vGIC and PL011? IHMO, the main difference is > Xen is taking care alone of the isolation between guest. Here in the TEE > case, you rely on a combination of both TEE and Xen to do the isolation. Yes. This is will be less secure, than TEE-only or hypervisor-only system. > > > >Look, I generally not against idea of TEE mediator in stubdoms. But this > >approach require many changes in existing XEN code: > > > >1. Load domains before Dom0. > > > >2. Add special API for mediator. Or alter existing ones. You can't use > > existing APIs as it, because you need to enforce stricter XSM rules > > on them. > > Mind giving more explanation....? Xen has a default policy for XSM and > indeed may not fit your use case. But you can write your own policy and load > it. Yes. You need policy "allow this stubdom to map memory only from TEE-enabled guests". AFAIK, this is not possible right now. But I can be wrong, I'm not very familiar with XSM. > > > >3. Changes in scheduling to allow TEE mediator use credits/slices of > > calling guest. > > > >4. Support boilerplate code in stubdom. You know, you can't simply > > write mediator in stubdom. You need a kernel. You need to > > maintain it. > > Well, in a way or another someone will have to maintain the mediator... The > kernel does not need to be specific to TEE, it could be a unikernel. Right. But for me XEN looks better maintained "kernel" :) IMHO, XEN is mature, there are less bugs (especially security ones) than in any other kernel. > And before you say again no-one in the community seem to be interested. I > should remind you that Arm is working on it (see development update). You are talking about that "unicore" project by NEC guys? Sorry, can't find mentioned development update. Looks like search on markmail is down (or I'm doing something terribly wrong). > > > >This is a lot of a work. It requires changes in generic parts of XEN. > >I fear it will be very hard to upstream such changes, because no one > >sees an immediate value in them. How do you think, what are my chances > >to upstream this? > > It is fairly annoying to see you justifying back most of this thread with > "no one sees an immediate value in them". > > I am not the only maintainers in Xen, so effectively can't promise whether > it is going to be upstreamed. But I believe the community has been very > supportive so far, a lot of discussions happened (see [2]) because of the > OP-TEE support. So what more do you expect from us? I'm sorry, I didn't mean to offend you or someone else. You, guys, can be harsh sometimes, but I really appreciate help provided by the community. And I, certainly, don't ask you about any guarantees or something of that sort. I'm just bothered by amount of required work and by upstreaming process. But this is not a strong argument against mediators in stubdoms, I think :) Currently I'm developing virtualization support in OP-TEE, so in meantime we'll have much time to discuss mediators and stubdomain approach (if you have time). To test this feature in OP-TEE I'm extending this RFC, making optee.c to look like full-scale mediator. I need to do this anyways, to test OP-TEE. When I'll finish, I can show you how mediator can look like. Maybe this will persuade you to one or another approach. > > > > >Approach in this RFC is much simpler. Few hooks in arch code + additional > >subsystem, which can be easily turned off. > > Stefano do you have any opinion on this discussion? > > Regards, > > > > >[1] https://wiki.xenproject.org/wiki/Outreach_Program_Projects > > [2] > https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg01931.html > -- WBR, Volodymyr Babchuk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-23 20:11 ` Volodymyr Babchuk @ 2017-10-23 21:26 ` Stefano Stabellini 2017-10-24 16:33 ` Volodymyr Babchuk 2017-10-24 17:33 ` Julien Grall 1 sibling, 1 reply; 44+ messages in thread From: Stefano Stabellini @ 2017-10-23 21:26 UTC (permalink / raw) To: Volodymyr Babchuk Cc: nd, Julien Grall, Julien Grall, Stefano Stabellini, xen-devel On Mon, 23 Oct 2017, Volodymyr Babchuk wrote: > > >This is a lot of a work. It requires changes in generic parts of XEN. > > >I fear it will be very hard to upstream such changes, because no one > > >sees an immediate value in them. How do you think, what are my chances > > >to upstream this? > > > > It is fairly annoying to see you justifying back most of this thread with > > "no one sees an immediate value in them". > > > > I am not the only maintainers in Xen, so effectively can't promise whether > > it is going to be upstreamed. But I believe the community has been very > > supportive so far, a lot of discussions happened (see [2]) because of the > > OP-TEE support. So what more do you expect from us? > I'm sorry, I didn't mean to offend you or someone else. You, guys, can > be harsh sometimes, but I really appreciate help provided by the > community. And I, certainly, don't ask you about any guarantees or > something of that sort. > > I'm just bothered by amount of required work and by upstreaming > process. But this is not a strong argument against mediators in > stubdoms, I think :) > > Currently I'm developing virtualization support in OP-TEE, so in > meantime we'll have much time to discuss mediators and stubdomain > approach (if you have time). To test this feature in OP-TEE I'm > extending this RFC, making optee.c to look like full-scale mediator. > I need to do this anyways, to test OP-TEE. When I'll finish, I can > show you how mediator can look like. Maybe this will persuade you to > one or another approach. Hi Volodymyr, We really appreciate your work and we care about your use-case. We really want this feature to be successful for you (and everybody else). Sorry if it doesn't always come out this way, but email conversations can sound "harsh" sometimes. However, keep in mind that both Julien and I are completely on your side on this work item. Please keep up with the good work :-) > > >Approach in this RFC is much simpler. Few hooks in arch code + additional > > >subsystem, which can be easily turned off. > > > > Stefano do you have any opinion on this discussion? We need to start somewhere, and I think this series could be a decent starting point. I think it is OK to have a small SMC filter in Xen. What Volodymyr is suggesting looks reasonable for now. As the code grows, we might found ourselves in the situation where we'll have to introduce stubdoms for TEE virtualization/emulation, and I think that's OK. Possibly, we'll have a "fast path" in Xen, only for filtering and small manipulations, and a "slow path" in the stubdom when more complex actions are necessary. For this series, I think we need a way to specify which domains can talk to TEE, so that we can only allow it for a specific subset of DomUs. I would probably use XSM for that. For the long term, I think both Volodymyr and us as maintainers need to be prepared to introduce stubdoms for TEE emulation. It will most probably happen as the feature-set grows. However, this small TEE framework in Xen could still be useful, and could be the basis for forwarding TEE requests to a stubdom for evaluation: maybe not all calls need to be forwarded to the stubdom, some of them could go directly to the firmware and this is where this series comes in. What do you think? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-23 21:26 ` Stefano Stabellini @ 2017-10-24 16:33 ` Volodymyr Babchuk 2017-10-24 21:33 ` Stefano Stabellini 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-24 16:33 UTC (permalink / raw) To: Stefano Stabellini; +Cc: nd, Julien Grall, Julien Grall, xen-devel Hello Stefano On Mon, Oct 23, 2017 at 02:26:56PM -0700, Stefano Stabellini wrote: > > > >This is a lot of a work. It requires changes in generic parts of XEN. > > > >I fear it will be very hard to upstream such changes, because no one > > > >sees an immediate value in them. How do you think, what are my chances > > > >to upstream this? > > > > > > It is fairly annoying to see you justifying back most of this thread with > > > "no one sees an immediate value in them". > > > > > > I am not the only maintainers in Xen, so effectively can't promise whether > > > it is going to be upstreamed. But I believe the community has been very > > > supportive so far, a lot of discussions happened (see [2]) because of the > > > OP-TEE support. So what more do you expect from us? > > I'm sorry, I didn't mean to offend you or someone else. You, guys, can > > be harsh sometimes, but I really appreciate help provided by the > > community. And I, certainly, don't ask you about any guarantees or > > something of that sort. > > > > I'm just bothered by amount of required work and by upstreaming > > process. But this is not a strong argument against mediators in > > stubdoms, I think :) > > > > Currently I'm developing virtualization support in OP-TEE, so in > > meantime we'll have much time to discuss mediators and stubdomain > > approach (if you have time). To test this feature in OP-TEE I'm > > extending this RFC, making optee.c to look like full-scale mediator. > > I need to do this anyways, to test OP-TEE. When I'll finish, I can > > show you how mediator can look like. Maybe this will persuade you to > > one or another approach. > > Hi Volodymyr, > > We really appreciate your work and we care about your use-case. We > really want this feature to be successful for you (and everybody else). > > Sorry if it doesn't always come out this way, but email conversations > can sound "harsh" sometimes. However, keep in mind that both Julien and > I are completely on your side on this work item. Please keep up with the > good work :-) Thanks :-) > > > > >Approach in this RFC is much simpler. Few hooks in arch code + additional > > > >subsystem, which can be easily turned off. > > > > > > Stefano do you have any opinion on this discussion? > > We need to start somewhere, and I think this series could be a decent > starting point. > > I think it is OK to have a small SMC filter in Xen. What Volodymyr is > suggesting looks reasonable for now. As the code grows, we might found > ourselves in the situation where we'll have to introduce stubdoms for > TEE virtualization/emulation, and I think that's OK. Possibly, we'll > have a "fast path" in Xen, only for filtering and small manipulations, > and a "slow path" in the stubdom when more complex actions are > necessary. This sounds a bit tricky, actually. If I got you right, you are proposing to split mediator into two parts. Only benefit I can see there - fast calls to OP-TEE from Dom0. That probably can work, but I need to consider all consequences... > For this series, I think we need a way to specify which domains can talk > to TEE, so that we can only allow it for a specific subset of DomUs. I > would probably use XSM for that. I am afraid, this is not possible. As other domains aren't 1:1 mapped, I need to have special translation code in mediator. Actually, I'm writing it rigth now to test my changes in OP-TEE. But event this is not enought for decent OP-TEE support. What can be done right now: 100% Dom0-only support with vanilla OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is even simplier task, so I can throw out some code from this patch series. On other hand, in the future this will lead to sutiation when two mediators for the same TEE shall be supported: one, simple, in XEN, another, fully-functional in stubdom. > For the long term, I think both Volodymyr and us as maintainers need to > be prepared to introduce stubdoms for TEE emulation. It will most > probably happen as the feature-set grows. However, this small TEE > framework in Xen could still be useful, and could be the basis for > forwarding TEE requests to a stubdom for evaluation: maybe not all calls > need to be forwarded to the stubdom, some of them could go directly to > the firmware and this is where this series comes in. > > What do you think? Hmm... I can't imagine how this can work for OP-TEE. In OP-TEE protocol, there is a number of "fast" (in SMCCC terms) service calls, which called mostly during initialization (to probe UID and version, to get shared region location, to exchange caps and so on) and one "yielding" (again, SMCCC term) call for actuall TEE tasks. The later one passes arguments in command buffer (not in registers), it can cause so-called RPC returns (when OP-TEE asks Normal World to perform certain work). Most of the mediator code will be devoted to handle this one type of call. So, I don't see benefit in splitting mediator between XEN and stubdom. At least for OP-TEE. Maybe this is not true for other TEEs. Looks like Google Trusty employs another approach for NW<->SW communication, maybe it can work in theirs case... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-24 16:33 ` Volodymyr Babchuk @ 2017-10-24 21:33 ` Stefano Stabellini 2017-10-27 13:47 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Stefano Stabellini @ 2017-10-24 21:33 UTC (permalink / raw) To: Volodymyr Babchuk Cc: nd, Stefano Stabellini, Julien Grall, Julien Grall, xen-devel On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: > > > > >Approach in this RFC is much simpler. Few hooks in arch code + additional > > > > >subsystem, which can be easily turned off. > > > > > > > > Stefano do you have any opinion on this discussion? > > > > We need to start somewhere, and I think this series could be a decent > > starting point. > > > > I think it is OK to have a small SMC filter in Xen. What Volodymyr is > > suggesting looks reasonable for now. As the code grows, we might found > > ourselves in the situation where we'll have to introduce stubdoms for > > TEE virtualization/emulation, and I think that's OK. Possibly, we'll > > have a "fast path" in Xen, only for filtering and small manipulations, > > and a "slow path" in the stubdom when more complex actions are > > necessary. > This sounds a bit tricky, actually. If I got you right, you are > proposing to split mediator into two parts. Only benefit I can see > there - fast calls to OP-TEE from Dom0. That probably can work, but I > need to consider all consequences... OK :-) > > For this series, I think we need a way to specify which domains can talk > > to TEE, so that we can only allow it for a specific subset of DomUs. I > > would probably use XSM for that. > I am afraid, this is not possible. As other domains aren't 1:1 mapped, > I need to have special translation code in mediator. Actually, I'm > writing it rigth now to test my changes in OP-TEE. But event this is > not enought for decent OP-TEE support. > What can be done right now: 100% Dom0-only support with vanilla > OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is > even simplier task, so I can throw out some code from this patch > series. On other hand, in the future this will lead to sutiation when > two mediators for the same TEE shall be supported: one, simple, in > XEN, another, fully-functional in stubdom. I think it is fine to support OP-TEE only in Dom0 to begin with. Ideally, it would be in Dom0 for convenience and speed and the OP-TEE capability would be specified as an XSM label. Ideally, it would not be only in Dom0 because it is tied to the 1:1 map, but I understand now that it is a requirement. I still think that the XSM label would be good to have even if today it cannot be changed as only Dom0 is 1:1. > > For the long term, I think both Volodymyr and us as maintainers need to > > be prepared to introduce stubdoms for TEE emulation. It will most > > probably happen as the feature-set grows. However, this small TEE > > framework in Xen could still be useful, and could be the basis for > > forwarding TEE requests to a stubdom for evaluation: maybe not all calls > > need to be forwarded to the stubdom, some of them could go directly to > > the firmware and this is where this series comes in. > > > > What do you think? > Hmm... I can't imagine how this can work for OP-TEE. In OP-TEE > protocol, there is a number of "fast" (in SMCCC terms) service calls, > which called mostly during initialization (to probe UID and version, > to get shared region location, to exchange caps and so on) and one > "yielding" (again, SMCCC term) call for actuall TEE tasks. The later > one passes arguments in command buffer (not in registers), it can > cause so-called RPC returns (when OP-TEE asks Normal World to perform > certain work). Most of the mediator code will be devoted to handle > this one type of call. So, I don't see benefit in splitting mediator > between XEN and stubdom. At least for OP-TEE. Maybe this is not true > for other TEEs. > Looks like Google Trusty employs another approach for NW<->SW > communication, maybe it can work in theirs case... It is possible to get a request from the command buffer in Xen, then forward it to the stubdom over a separate ring. This is pretty much how QEMU works on x86 to do emulation: IO accesses are trapped in Xen, then Xen issues requests to QEMU over a special ring. Xen doesn't need to forward to QEMU all requests: some of them could be handled directly in Xen. But maybe this model doesn't actually make sense for OP-TEE? Would it make sense to extract a request from the ring in Xen then evaluate whether it should be handled in Xen, forwarded to the firmware, or forwarded to a stubdom? For example, would it be possible to forward to firmware accesses to certain TAs while forwarding to a stubdom accesses to other TAs? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-24 21:33 ` Stefano Stabellini @ 2017-10-27 13:47 ` Julien Grall 2017-10-27 19:59 ` Stefano Stabellini 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-27 13:47 UTC (permalink / raw) To: Stefano Stabellini, Volodymyr Babchuk; +Cc: Julien Grall, nd, xen-devel Hi, Just answering to dom0 been 1:1 domain. On 24/10/17 22:33, Stefano Stabellini wrote: > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: >>> For this series, I think we need a way to specify which domains can talk >>> to TEE, so that we can only allow it for a specific subset of DomUs. I >>> would probably use XSM for that. >> I am afraid, this is not possible. As other domains aren't 1:1 mapped, >> I need to have special translation code in mediator. Actually, I'm >> writing it rigth now to test my changes in OP-TEE. But event this is >> not enought for decent OP-TEE support. >> What can be done right now: 100% Dom0-only support with vanilla >> OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is >> even simplier task, so I can throw out some code from this patch >> series. On other hand, in the future this will lead to sutiation when >> two mediators for the same TEE shall be supported: one, simple, in >> XEN, another, fully-functional in stubdom. > > I think it is fine to support OP-TEE only in Dom0 to begin with. > > Ideally, it would be in Dom0 for convenience and speed and the OP-TEE > capability would be specified as an XSM label. Ideally, it would not be > only in Dom0 because it is tied to the 1:1 map, but I understand now > that it is a requirement. I still think that the XSM label would be good > to have even if today it cannot be changed as only Dom0 is 1:1. I thought a bit more about Dom0 been a 1:1 domain. It is only true for Device Memory and the initial RAM allocated for Dom0. Dom0 may balloon out some pages because it has to map region belonging to other domain. Those regions will not be 1:1 mapped and translation will be needed if used. The problem is very similar to DMA in dom0. I can't see any reason to not use those regions with OP-TEE. Am I wrong here? Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-27 13:47 ` Julien Grall @ 2017-10-27 19:59 ` Stefano Stabellini 2017-10-27 20:06 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Stefano Stabellini @ 2017-10-27 19:59 UTC (permalink / raw) To: Julien Grall Cc: nd, Stefano Stabellini, Volodymyr Babchuk, Julien Grall, xen-devel On Fri, 27 Oct 2017, Julien Grall wrote: > Hi, > > Just answering to dom0 been 1:1 domain. > > On 24/10/17 22:33, Stefano Stabellini wrote: > > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: > > > > For this series, I think we need a way to specify which domains can talk > > > > to TEE, so that we can only allow it for a specific subset of DomUs. I > > > > would probably use XSM for that. > > > I am afraid, this is not possible. As other domains aren't 1:1 mapped, > > > I need to have special translation code in mediator. Actually, I'm > > > writing it rigth now to test my changes in OP-TEE. But event this is > > > not enought for decent OP-TEE support. > > > What can be done right now: 100% Dom0-only support with vanilla > > > OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is > > > even simplier task, so I can throw out some code from this patch > > > series. On other hand, in the future this will lead to sutiation when > > > two mediators for the same TEE shall be supported: one, simple, in > > > XEN, another, fully-functional in stubdom. > > > > I think it is fine to support OP-TEE only in Dom0 to begin with. > > > > Ideally, it would be in Dom0 for convenience and speed and the OP-TEE > > capability would be specified as an XSM label. Ideally, it would not be > > only in Dom0 because it is tied to the 1:1 map, but I understand now > > that it is a requirement. I still think that the XSM label would be good > > to have even if today it cannot be changed as only Dom0 is 1:1. > > I thought a bit more about Dom0 been a 1:1 domain. It is only true for Device > Memory and the initial RAM allocated for Dom0. > > Dom0 may balloon out some pages because it has to map region belonging to > other domain. Those regions will not be 1:1 mapped and translation will be > needed if used. > > The problem is very similar to DMA in dom0. I can't see any reason to not use > those regions with OP-TEE. Am I wrong here? I think you are right. For DMA, Dom0 is expected to use the swiotlb-xen driver to solve the problem, because it is a genuine use case to have foreign grants involved in a DMA operation. For OP-TEE, I don't think we need to support this case? Xen could fail the request if it involves a page that is not 1:1 mapped? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-27 19:59 ` Stefano Stabellini @ 2017-10-27 20:06 ` Julien Grall 0 siblings, 0 replies; 44+ messages in thread From: Julien Grall @ 2017-10-27 20:06 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Julien Grall, nd, Volodymyr Babchuk, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2551 bytes --] On 27 Oct 2017 20:59, "Stefano Stabellini" <sstabellini@kernel.org> wrote: On Fri, 27 Oct 2017, Julien Grall wrote: > Hi, > > Just answering to dom0 been 1:1 domain. > > On 24/10/17 22:33, Stefano Stabellini wrote: > > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: > > > > For this series, I think we need a way to specify which domains can talk > > > > to TEE, so that we can only allow it for a specific subset of DomUs. I > > > > would probably use XSM for that. > > > I am afraid, this is not possible. As other domains aren't 1:1 mapped, > > > I need to have special translation code in mediator. Actually, I'm > > > writing it rigth now to test my changes in OP-TEE. But event this is > > > not enought for decent OP-TEE support. > > > What can be done right now: 100% Dom0-only support with vanilla > > > OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is > > > even simplier task, so I can throw out some code from this patch > > > series. On other hand, in the future this will lead to sutiation when > > > two mediators for the same TEE shall be supported: one, simple, in > > > XEN, another, fully-functional in stubdom. > > > > I think it is fine to support OP-TEE only in Dom0 to begin with. > > > > Ideally, it would be in Dom0 for convenience and speed and the OP-TEE > > capability would be specified as an XSM label. Ideally, it would not be > > only in Dom0 because it is tied to the 1:1 map, but I understand now > > that it is a requirement. I still think that the XSM label would be good > > to have even if today it cannot be changed as only Dom0 is 1:1. > > I thought a bit more about Dom0 been a 1:1 domain. It is only true for Device > Memory and the initial RAM allocated for Dom0. > > Dom0 may balloon out some pages because it has to map region belonging to > other domain. Those regions will not be 1:1 mapped and translation will be > needed if used. > > The problem is very similar to DMA in dom0. I can't see any reason to not use > those regions with OP-TEE. Am I wrong here? I think you are right. For DMA, Dom0 is expected to use the swiotlb-xen driver to solve the problem, because it is a genuine use case to have foreign grants involved in a DMA operation. For OP-TEE, I don't think we need to support this case? Xen could fail the request if it involves a page that is not 1:1 mapped? You would need to introspect the message in order to know that. So supporting non 1:1 mapped page would not be more difficult. This assuming that you know when you OP-TEE is done with the page. Cheers, [-- Attachment #1.2: Type: text/html, Size: 3558 bytes --] [-- Attachment #2: Type: text/plain, Size: 127 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-23 20:11 ` Volodymyr Babchuk 2017-10-23 21:26 ` Stefano Stabellini @ 2017-10-24 17:33 ` Julien Grall 2017-10-24 19:02 ` Volodymyr Babchuk 1 sibling, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-10-24 17:33 UTC (permalink / raw) To: Volodymyr Babchuk; +Cc: Julien Grall, nd, Stefano Stabellini, xen-devel Hi, On 23/10/17 21:11, Volodymyr Babchuk wrote: > On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote: > >> Hi Volodymyr, > Hi Julien, > >> Let me begin the e-mail with I am not totally adversed to putting the TEE >> mediator in Xen. At the moment, I am trying to understand the whole picture. > Thanks for clarification. This is really reassuring :) > In my turn, I'm not totally against TEE mediators in stubdoms. I'm only > concerned about required efforts. > >> On 20/10/17 18:37, Volodymyr Babchuk wrote: >>> On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote: >>>> On 17/10/17 16:59, Volodymyr Babchuk wrote: >>>>> On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: >>>>>> On 11/10/17 20:01, Volodymyr Babchuk wrote: >>>>>>> I want to present TEE mediator, that was discussed earlier ([1]). >>>>>>> >>>>>>> I selected design with built-in mediators. This is easiest way, >>>>>>> it removes many questions, it is easy to implement and maintain >>>>>>> (at least I hope so). >>>>>> >>>>>> Well, it may close the technical questions but still leave the security >>>>>> impact unanswered. I would have appreciated a summary of each approach and >>>>>> explain the pros/cons. >>>>> This is the most secure way also. In terms of trust between guests and >>>>> Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about >>>>> "security", my first thoughts are "Can TEE OS trust to XEN as a >>>>> mediator? Can TEE client trust to XEN as a mediator?". And with >>>>> current approach answer is "yes, they can, especially if XEN is a part >>>>> of a chain of trust". >>>>> >>>>> But you probably wanted to ask "Can guest compromise whole system by >>>>> using TEE mediator or TEE OS?". This is an interesting question. >>>>> First let's discuss requirements for a TEE mediator. So, mediator >>>>> should be able to: >>>>> >>>>> * Receive request to handle trapped SMC. This request should include >>>>> user registers + some information about guest (at least domain id). >>>>> * Pin/unpin domain memory pages. >>>>> * Map domain memory pages into own address space with RW access. >>>>> * Issue real SMC to a TEE. >>>>> * Receive information about guest creation and destruction. >>>>> * (Probably) inject IRQs into a domain (this can be not a requester domain, >>>>> but some other domain, that also called to TEE). >>>>> >>>>> This is a minimal list of requirements. I think, this should be enough to >>>>> implement mediator for OP-TEE. But I can't say for sure for other TEEs. >>>>> >>>>> Let's consider possible approaches: >>>>> >>>>> 1. Mediator right in XEN, works at EL2. >>>>> Pros: >>>>> * Mediator can use all XEN APIs >>>>> * As mediator resides in XEN, it can be checked together with XEN >>>>> for a validity (trusted boot). >>>>> * Mediator is initialized before Dom0. Dom0 can work with a TEE. >>>>> * No extra context switches, no special ABI between XEN and mediator. >>>>> >>>>> Cons: >>>>> * Because it lives in EL2, it can compromise whole hypervisor, >>>>> if there is a security bug in mediator code. >>>>> * No support for closed source TEEs. >>>> >>>> Another cons is you assume TEE API is fully stable and will not change. >>>> Imagine a new function is added, or a vendor decided to hence with a new set >>>> of API. How will you know Xen is safe to use it? >>> With whitelisting, as you correctly suggested below. XEN will process >>> only know requests. Anything that looks unfimiliar should be rejected. >> >> Let's imagine the guest is running on a platform with a newer version of >> TEE. This guest will probe the version of OP-TEE and knows the new function >> is present. > This request will be handled mediator. At this moment, OP-TEE client does > not use versions. Instead it uses capability flags. So, mediator should > filter all unknown caps. This will force guest to use only supported > subset of features. One more question. Does it mean new functions will never be added in current capabilities? > If, in the future, client will relly on versions (i.e. due to dramatic > protocol change), mediator can either downgrade version or refuse to work > at all. Makes sense. > >> If as you said Xen is using a whitelist, this means the hypervisor will >> return unimplemented. >> How do you expect the guest to behave in that case? > As I said above, guest should downgrade to supported features subset. > >> Note that I think a whitelist is a good idea, but I think we need to think a >> bit more about the implication. > At least now OP-TEE is designed in a such way, that it is compatible in both > ways. I'm sure that future OP-TEE development will be done with virtualization > support in mind, so it will not break existing setups. It would be good to have the two communities talking together. So we can make sure the virtualization support is not going in the wrong direction. Similarly, it would be nice that someone from the OP-TEE maintainers give feedback on the approach suggested in Xen. > >>> >>>> If it is not safe, this means you have a whitelist solution and therefore >>>> tie Xen to a specific OP-TEE version. So if you need to use a new function >>>> you would need to upgrade Xen making the code of using new version >>>> potentially high. >>> Yes, any ABI change between OP-TEE and its clients will require mediator >>> upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll >>> install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, >>> which is known to XEN. >>> >>>> Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you >>>> impose anyone wanted to modify OP-TEE for their own purpose can make a >>>> closed version of the TEE. But if you need to introspect/whitelist call, you >>>> impose the vendor to expose their API. >>> Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. >>> If vendor modifies interface between OP-TEE and Linux, they anyways obligued >>> to expose API. >> >> Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. >> >> My understanding is the OP-TEE will provide a generic way to access >> different Trusted Application. While OP-TEE API may be generic, the TA API >> is custom. AFAICT the latter is not part of Linux driver. > Yes, you are perfectly right there. > >> So here my questions: >> 1) Are you planning allow all the guests to access every Trusted >> Applications? > This is a good question. There are two types of TAs supported in > OP-TEE: real TAs (as they are described in GlobalPlatform specs) and > PseudoTAs. The latter ones are statically linked right into OP-TEE > kernel and execute at S-EL1 level. > Real TAs are provided by client. That means that NW userspace > supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA > and then runs it in S-EL0. > So, I'm planning to allow client to work with any real TA. I can't see > real problem there. Are the real TAs going to be shared between guests? Or will each guest have their own one? Will you allow every guests loading real TAs? > PseudoTAs can be used to access some platform-specific features, and thus > it can be quite dangerous to allow anyone call them. > But, generic OP-TEE includes only test and benchmark PseudoTAs, that > should be disabled on production builds. So, I don't see why generic > mediator should distinguish them. I think, XSM can be employed later > to control which guest can access which PseudoTA. But this is not > target for first version. I guess the first version will forbid access to PseudoTA from all the guests but Dom0? >> 2) Will you ever need to introspect those messages? > No, I don't. I guess that's because all the TAs should followed the specified message protocol? > >>>>> >>>>> 2. Mediator in a stubdomain. Works at EL1. >>>>> Pros: >>>>> * Mediator is isolated from hypervisor (but it still can do potentially >>>>> dangerous things like mapping domain memory or pining pages). >>>>> * One can legally create and use mediator for a closed-source TEE. >>>> >>>> * Easier to upgrade to a new version of OP-TEE. >>> Yes, this is true. But what about interface between XEN and mediator? >>> This is a new entity that should be maintained. Will I abe able to use >>> new XEN with old mediator? Or new mediator with old XEN? >> >> Why would you need to specific interface for the mediator? (see more below) > At least following features in XEN control (I hope this is right term) API > are missing right now: > - domain creation/destruction hooks > - ability to intercept only certain SMCs > - way to inject IRQs to other guests > > Also, see more below >>> >>>>>> Cons: >>>>> * Overhead in XEN<->Mediator communication. >>>>> * XEN needs to be modified to boot mediator domain before Dom0. >>>> >>>> Is it a really cons? In the past, we had discussion to allow Xen creating >>>> multiple domain, avoiding the overhead of Dom0. This could also benefits >>>> here. >>> As I understand, this is a significant change in XEN. What are the chances, >>> that community will accept this change? As I can see, immediate benefit >>> of this is only TEE mediator support. Looks like no one except us >>> interested in this topic. >> >> The GSOC project was not added because of TEE mediator. We had companies >> showing interest to start multiple domains at the same time. This would >> significantly shrink down the boot time of the whole platform. > Yes. Actually, we also interested in a faster boot. But my point was > that what we need for mediator is not the same that is described in > GSOC project. Functionality described at GSOC page has multiple uses. > But for mediator we need something more intricate: as I said below, > ability to delay boot of hwdom (and other domains). Not really, you could the domain could block when issuing an SMC until the mediator is up and running. > >>> >>> BTW, I checked "Xen on ARM: create multiple guests from device >>> tree" at [1]. This is close, to what we need, but not exactly. You see, >>> TEE mediator should be created *before* Dom0. So actually TEE mediator >>> will receive domid 0. I suspect that this only change will break >>> many things. >> >> Can you please give example? > I'm sure that I seen checks for domid == 0 before, but now I can't find any. > Probably, that was closed-source backends. So, sorry for false accusation :) > >> Technically none of the hypervisor, Linux and the toolstack should rely on >> dom0 to be domid 0. >> >> AFAIK, the hypervisor and Linux are free of them. It might be possible to >> have few hardcoded in the toolstack, but they should really disappear. > Totaly agree there. > >> However, I can't see why you require the mediator to use domid 0. You could >> for example keep the hardware domain paused until the mediator has started. > So this will like: construct dom0, construct and run mediator domain, > run dom0 by signal from DomMediator? Probably this will work. > >>> >>>>> >>>>> And yes, it seems obvious, but I want to say this explicitly: generic >>>>> TEE mediator framework should and will use XSM to control which domain >>>>> can work with TEE. So, if you don't trust your guest - don't let it >>>>> to call TEE at all. >>>> >>>> Correct me if I am wrong. TEE could be used by Android guest which likely >>>> run the user apps... right? So are you saying you fully trust that guest and >>>> obviously the user installing rogue app? >>> I don't think that app downloaded from Play Marget can access OP-TEE directly. >>> OP-TEE can be used by Android itself as a key storage or to access to a SE, >>> for example. But 3rd app that issues TEE calls... I don't think so. >> >> You didn't get my point here. That rogue app may be able to break into >> kernel via an exploit or have enough privilege to break the guest. Who knows >> what it will be able to do after... > Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed > to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide > some safer environment for sensitive data and code. This environment has > well-defined interfaces and is desgined to be as safe as possible. > > If rogue app breaks into kernel, then it can issue any SMC which it wants. > But OP-TEE does not trust to NW. Hypervisor does not trust to guests. > Mediator should be written in the same way. > > So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is > known issue. If there is a security bug in OP-TEE, it probably can overcome > whole system. But this is true for any system running OP-TEE. I agree that if you take over OP-TEE, you will take over any system. This is not specific to hypervisor. Baremetal OS taking down the platform will only harm itself. A guest OS could harm the whole platform. What I am not sure yet, maybe because of my lack of knowledge around OP-TEE, who is going to protect a TA to access all the NS memory? > > If there is a security flaw in mediator - it can compromise either hypervisor, > or DomMediator and all TEE-capable guests. Yes, this is a risk. > >> The whole point of using an hypervisor is to isolate guest from each other. >> So what is the isolation model with OP-TEE and the mediator? > OP-TEE is written to isolate TAs, resources and clients from each other. > Currently there are no plans for interaction between TAs from different VMs, > no resource sharing, nothing like this. > What do you mean under "isolation model"? Can you give some example? By that I meant, who is going to prevent guest A to access guest B data. I think you partly answered to my question by the "OP-TEE is written to isolate TAs". The access to NS memory question above will fill the rest I think. > >>> >>>>> This feature is not implemented in this RFC only because >>>>> currently only Dom0 calls are supported. >>>>> >>>>>> This would help to understand that maybe it is an easy way but also still >>>>>> secure... >>>>> In previous discussion we considered only two variants: in XEN or outside >>>>> XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. >>>>> Such stubdomain will need access to all guests memory. If you managed to >>>>> gain control on mediator stubdomain, you can do anything you want with all >>>>> guests. >>>> >>>> That's slightly untrue. The stubdomain will only be able to mess with >>>> domains using TEE. >>> Yes, this is more strict. Then either you are not allowing your privileged >>> domain to use TEE, or your system may be compromised anyways. >> >> Can you give an example of privilege domain for you? Do you consider Android >> a privilege domain? > In this case I used term "priviliged domain" in XEN meaning: is_privileged == 1. > Android is not privileged domain, by all means. > I wanted to say that you if you allow Dom0 to access TEE, then hacked DomMediator > can compromise Dom0 and the hypervisor. And I never disagreed in that. This is the non-controversial part :). > >>>>> >>>>>> To be clear, this series don't look controversial at least for OP-TEE. What >>>>>> I am more concerned is about DomU supports. >>>>> Your concern is that rogue DomU can compromise whole system, right? >>>> >>>> Yes. You seem to assume that DomU using TEE will always be trusted, I think >>>> this is the wrong approach if the use is able to interact directly with >>>> those guests. See above. >>> No, I am not assuming that DomU that calls TEE should be trusted. Why do you >>> think so? It should be able to use TEE services, but this does not mean that >>> XEN should trust it. >> >> In a previous answer you said: "So, if you don't trust your guest - don't >> let it". For me, this clearly means you consider that DomU using TEE are >> trusted. >> >> So can you clarify by what you mean by trust then? > Well... In real world "trust" isn't binary option. You don't want to > allow all domains to access TEE. Breached TEE user domain doesn't > automatically mean that your whole system is compromised. But this > certainly increases attack surface. So it is safer to give TEE access > only to those domains, which really require it. You can call them > sligtly more trusted, then others. Do you have an example of guest you would slightly trust more? > >>> Even now, XEN processes requests from DomUs without >>> trusting them. Why do you think, that TEE mediator usage will differ? >> >> I guess you are comparing with vGIC and PL011? IHMO, the main difference is >> Xen is taking care alone of the isolation between guest. Here in the TEE >> case, you rely on a combination of both TEE and Xen to do the isolation. > Yes. This is will be less secure, than TEE-only or hypervisor-only system. Can you expand here? > >>> >>> Look, I generally not against idea of TEE mediator in stubdoms. But this >>> approach require many changes in existing XEN code: >>> >>> 1. Load domains before Dom0. >>> >>> 2. Add special API for mediator. Or alter existing ones. You can't use >>> existing APIs as it, because you need to enforce stricter XSM rules >>> on them. >> >> Mind giving more explanation....? Xen has a default policy for XSM and >> indeed may not fit your use case. But you can write your own policy and load >> it. > Yes. You need policy "allow this stubdom to map memory only from TEE-enabled > guests". AFAIK, this is not possible right now. But I can be wrong, I'm > not very familiar with XSM. I believe XSM could do that. IIRC, you can "label" your domain and use that to say "stubdom is allowed to access memory with domain using the given label". > >>> >>> 3. Changes in scheduling to allow TEE mediator use credits/slices of >>> calling guest. >>> >>> 4. Support boilerplate code in stubdom. You know, you can't simply >>> write mediator in stubdom. You need a kernel. You need to >>> maintain it. >> >> Well, in a way or another someone will have to maintain the mediator... The >> kernel does not need to be specific to TEE, it could be a unikernel. > Right. But for me XEN looks better maintained "kernel" :) > IMHO, XEN is mature, there are less bugs (especially security ones) > than in any other kernel. > >> And before you say again no-one in the community seem to be interested. I >> should remind you that Arm is working on it (see development update). > You are talking about that "unicore" project by NEC guys? Sorry, > can't find mentioned development update. Looks like search on markmail > is down (or I'm doing something terribly wrong). Sorry, I meant Mini-OS. I don't know any work on "unicore" for Arm64 for now. > >>> >>> This is a lot of a work. It requires changes in generic parts of XEN. >>> I fear it will be very hard to upstream such changes, because no one >>> sees an immediate value in them. How do you think, what are my chances >>> to upstream this? >> >> It is fairly annoying to see you justifying back most of this thread with >> "no one sees an immediate value in them". >> >> I am not the only maintainers in Xen, so effectively can't promise whether >> it is going to be upstreamed. But I believe the community has been very >> supportive so far, a lot of discussions happened (see [2]) because of the >> OP-TEE support. So what more do you expect from us? > I'm sorry, I didn't mean to offend you or someone else. You, guys, can > be harsh sometimes, but I really appreciate help provided by the > community. And I, certainly, don't ask you about any guarantees or > something of that sort. > > I'm just bothered by amount of required work and by upstreaming > process. But this is not a strong argument against mediators in > stubdoms, I think :) > > Currently I'm developing virtualization support in OP-TEE, so in > meantime we'll have much time to discuss mediators and stubdomain > approach (if you have time). To test this feature in OP-TEE I'm > extending this RFC, making optee.c to look like full-scale mediator. > I need to do this anyways, to test OP-TEE. When I'll finish, I can > show you how mediator can look like. Maybe this will persuade you to > one or another approach. I think this would be useful. Can you also keep both Stefano (I assume he wants too) and I in the loop for the OP-TEE virtualization side? Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-24 17:33 ` Julien Grall @ 2017-10-24 19:02 ` Volodymyr Babchuk 2017-11-02 13:17 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-10-24 19:02 UTC (permalink / raw) To: Julien Grall, jens.wiklander Cc: Julien Grall, nd, Stefano Stabellini, xen-devel Hi Julien, Jens, I'm looped in Jens Wiklander. He is one of OP-TEE maintainers. He also maintains TEE subsytem in Linux kernel. I CC'ed him in 4/4 patch, because only it concerned OP-TEE. But looks like discussion in this thread revolves primarily over OP-TEE, so I'm adding him there. Jens, if you want to catch up, you can find whole thread at [1]. On Tue, Oct 24, 2017 at 06:33:20PM +0100, Julien Grall wrote: > Hi, > > On 23/10/17 21:11, Volodymyr Babchuk wrote: > >On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote: > > > >>Hi Volodymyr, > >Hi Julien, > > > >>Let me begin the e-mail with I am not totally adversed to putting the TEE > >>mediator in Xen. At the moment, I am trying to understand the whole picture. > >Thanks for clarification. This is really reassuring :) > >In my turn, I'm not totally against TEE mediators in stubdoms. I'm only > >concerned about required efforts. > > > >>On 20/10/17 18:37, Volodymyr Babchuk wrote: > >>>On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote: > >>>>On 17/10/17 16:59, Volodymyr Babchuk wrote: > >>>>>On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: > >>>>>>On 11/10/17 20:01, Volodymyr Babchuk wrote: > >>>>>>>I want to present TEE mediator, that was discussed earlier ([1]). > >>>>>>> > >>>>>>>I selected design with built-in mediators. This is easiest way, > >>>>>>>it removes many questions, it is easy to implement and maintain > >>>>>>>(at least I hope so). > >>>>>> > >>>>>>Well, it may close the technical questions but still leave the security > >>>>>>impact unanswered. I would have appreciated a summary of each approach and > >>>>>>explain the pros/cons. > >>>>>This is the most secure way also. In terms of trust between guests and > >>>>>Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about > >>>>>"security", my first thoughts are "Can TEE OS trust to XEN as a > >>>>>mediator? Can TEE client trust to XEN as a mediator?". And with > >>>>>current approach answer is "yes, they can, especially if XEN is a part > >>>>>of a chain of trust". > >>>>> > >>>>>But you probably wanted to ask "Can guest compromise whole system by > >>>>>using TEE mediator or TEE OS?". This is an interesting question. > >>>>>First let's discuss requirements for a TEE mediator. So, mediator > >>>>>should be able to: > >>>>> > >>>>> * Receive request to handle trapped SMC. This request should include > >>>>> user registers + some information about guest (at least domain id). > >>>>> * Pin/unpin domain memory pages. > >>>>> * Map domain memory pages into own address space with RW access. > >>>>> * Issue real SMC to a TEE. > >>>>> * Receive information about guest creation and destruction. > >>>>> * (Probably) inject IRQs into a domain (this can be not a requester domain, > >>>>> but some other domain, that also called to TEE). > >>>>> > >>>>>This is a minimal list of requirements. I think, this should be enough to > >>>>>implement mediator for OP-TEE. But I can't say for sure for other TEEs. > >>>>> > >>>>>Let's consider possible approaches: > >>>>> > >>>>>1. Mediator right in XEN, works at EL2. > >>>>> Pros: > >>>>> * Mediator can use all XEN APIs > >>>>> * As mediator resides in XEN, it can be checked together with XEN > >>>>> for a validity (trusted boot). > >>>>> * Mediator is initialized before Dom0. Dom0 can work with a TEE. > >>>>> * No extra context switches, no special ABI between XEN and mediator. > >>>>> > >>>>> Cons: > >>>>> * Because it lives in EL2, it can compromise whole hypervisor, > >>>>> if there is a security bug in mediator code. > >>>>> * No support for closed source TEEs. > >>>> > >>>>Another cons is you assume TEE API is fully stable and will not change. > >>>>Imagine a new function is added, or a vendor decided to hence with a new set > >>>>of API. How will you know Xen is safe to use it? > >>>With whitelisting, as you correctly suggested below. XEN will process > >>>only know requests. Anything that looks unfimiliar should be rejected. > >> > >>Let's imagine the guest is running on a platform with a newer version of > >>TEE. This guest will probe the version of OP-TEE and knows the new function > >>is present. > >This request will be handled mediator. At this moment, OP-TEE client does > >not use versions. Instead it uses capability flags. So, mediator should > >filter all unknown caps. This will force guest to use only supported > >subset of features. > > One more question. Does it mean new functions will never be added in current > capabilities? AFAIK, now. That would break backward compatibility. > >If, in the future, client will relly on versions (i.e. due to dramatic > >protocol change), mediator can either downgrade version or refuse to work > >at all. > > Makes sense. > > > > >>If as you said Xen is using a whitelist, this means the hypervisor will > >>return unimplemented. > >>How do you expect the guest to behave in that case? > >As I said above, guest should downgrade to supported features subset. > > > >>Note that I think a whitelist is a good idea, but I think we need to think a > >>bit more about the implication. > >At least now OP-TEE is designed in a such way, that it is compatible in both > >ways. I'm sure that future OP-TEE development will be done with virtualization > >support in mind, so it will not break existing setups. > > It would be good to have the two communities talking together. So we can > make sure the virtualization support is not going in the wrong direction. > > Similarly, it would be nice that someone from the OP-TEE maintainers give > feedback on the approach suggested in Xen. Yep. I added Jens, as I said above. > > > >>> > >>>>If it is not safe, this means you have a whitelist solution and therefore > >>>>tie Xen to a specific OP-TEE version. So if you need to use a new function > >>>>you would need to upgrade Xen making the code of using new version > >>>>potentially high. > >>>Yes, any ABI change between OP-TEE and its clients will require mediator > >>>upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll > >>>install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, > >>>which is known to XEN. > >>> > >>>>Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you > >>>>impose anyone wanted to modify OP-TEE for their own purpose can make a > >>>>closed version of the TEE. But if you need to introspect/whitelist call, you > >>>>impose the vendor to expose their API. > >>>Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. > >>>If vendor modifies interface between OP-TEE and Linux, they anyways obligued > >>>to expose API. > >> > >>Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. > >> > >>My understanding is the OP-TEE will provide a generic way to access > >>different Trusted Application. While OP-TEE API may be generic, the TA API > >>is custom. AFAICT the latter is not part of Linux driver. > >Yes, you are perfectly right there. > > > >>So here my questions: > >> 1) Are you planning allow all the guests to access every Trusted > >>Applications? > >This is a good question. There are two types of TAs supported in > >OP-TEE: real TAs (as they are described in GlobalPlatform specs) and > >PseudoTAs. The latter ones are statically linked right into OP-TEE > >kernel and execute at S-EL1 level. > >Real TAs are provided by client. That means that NW userspace > >supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA > >and then runs it in S-EL0. > >So, I'm planning to allow client to work with any real TA. I can't see > >real problem there. > > Are the real TAs going to be shared between guests? Or will each guest have > their own one? No, we don't plan this. At least at this momoent. Every guest will have own instance of TA. > Will you allow every guests loading real TAs? Yes, if guest has access to TEE, it can load TA. Either there is no sense to use TEE. OP-TEE core itself does not provide useful services to clients. Just to be sure: client can't execute any code as TA. TA should be signed by product vendor. In real world you can't take TA from product A and run it on product B, even if they are built on the same SoC. Every product vendor should generate own set of keys and install them in OP-TEE. > >PseudoTAs can be used to access some platform-specific features, and thus > >it can be quite dangerous to allow anyone call them. > >But, generic OP-TEE includes only test and benchmark PseudoTAs, that > >should be disabled on production builds. So, I don't see why generic > >mediator should distinguish them. I think, XSM can be employed later > >to control which guest can access which PseudoTA. But this is not > >target for first version. > > I guess the first version will forbid access to PseudoTA from all the guests > but Dom0? Actually no. All TAs are identified by UUIDs. Mediator can distinguish TA from PseudoTA. I have in mind another argument: vanilla OP-TEE does not offer any production PseudoTAs. If platform\product vendor extends OP-TEE with some PTAs, then they should add corresponding filtering functionality in mediator. Because only vendor know what given PTA does and how it can affect system security. > > >> 2) Will you ever need to introspect those messages? > >No, I don't. > > I guess that's because all the TAs should followed the specified message > protocol? Something like that. GlobalPlatform defines API for TAs and clients. Basically this API have primary 4 commands: OpenSession, CloseSession, InvokeCommand, RequestCancelation. Command is identified by integer number. This command number have meaning only for certain TA. So, for example, command number 8 to TA A can mean "generate random number for me", while command number 8 to TA B can mean "make payment". Every TEE implements protocol for this calls is it wishes. This means, that GlobalPlatform does not define how OP-TEE client should send this requests to OP-TEE OS. Mediator will see that client calls InvokeCommain function, but it have no idea what this command will do. And it don't have to. At this level of protocol OP-TEE itself ensures integrity. > > > >>>>> > >>>>>2. Mediator in a stubdomain. Works at EL1. > >>>>> Pros: > >>>>> * Mediator is isolated from hypervisor (but it still can do potentially > >>>>> dangerous things like mapping domain memory or pining pages). > >>>>> * One can legally create and use mediator for a closed-source TEE. > >>>> > >>>> * Easier to upgrade to a new version of OP-TEE. > >>>Yes, this is true. But what about interface between XEN and mediator? > >>>This is a new entity that should be maintained. Will I abe able to use > >>>new XEN with old mediator? Or new mediator with old XEN? > >> > >>Why would you need to specific interface for the mediator? (see more below) > >At least following features in XEN control (I hope this is right term) API > >are missing right now: > > - domain creation/destruction hooks > > - ability to intercept only certain SMCs > > - way to inject IRQs to other guests > > > >Also, see more below > >>> > >>>>>> Cons: > >>>>> * Overhead in XEN<->Mediator communication. > >>>>> * XEN needs to be modified to boot mediator domain before Dom0. > >>>> > >>>>Is it a really cons? In the past, we had discussion to allow Xen creating > >>>>multiple domain, avoiding the overhead of Dom0. This could also benefits > >>>>here. > >>>As I understand, this is a significant change in XEN. What are the chances, > >>>that community will accept this change? As I can see, immediate benefit > >>>of this is only TEE mediator support. Looks like no one except us > >>>interested in this topic. > >> > >>The GSOC project was not added because of TEE mediator. We had companies > >>showing interest to start multiple domains at the same time. This would > >>significantly shrink down the boot time of the whole platform. > >Yes. Actually, we also interested in a faster boot. But my point was > >that what we need for mediator is not the same that is described in > >GSOC project. Functionality described at GSOC page has multiple uses. > >But for mediator we need something more intricate: as I said below, > >ability to delay boot of hwdom (and other domains). > > Not really, you could the domain could block when issuing an SMC until the > mediator is up and running. Do you mean, that if domain tries to execute SMC, and mediator is not ready, then hypervisor should pause all domain's vCPUs? That can be destructive for hw domain. > > > >>> > >>>BTW, I checked "Xen on ARM: create multiple guests from device > >>>tree" at [1]. This is close, to what we need, but not exactly. You see, > >>>TEE mediator should be created *before* Dom0. So actually TEE mediator > >>>will receive domid 0. I suspect that this only change will break > >>>many things. > >> > >>Can you please give example? > >I'm sure that I seen checks for domid == 0 before, but now I can't find any. > >Probably, that was closed-source backends. So, sorry for false accusation :) > > > >>Technically none of the hypervisor, Linux and the toolstack should rely on > >>dom0 to be domid 0. > >> > >>AFAIK, the hypervisor and Linux are free of them. It might be possible to > >>have few hardcoded in the toolstack, but they should really disappear. > >Totaly agree there. > > > >>However, I can't see why you require the mediator to use domid 0. You could > >>for example keep the hardware domain paused until the mediator has started. > >So this will like: construct dom0, construct and run mediator domain, > >run dom0 by signal from DomMediator? Probably this will work. > > > >>> > >>>>> > >>>>>And yes, it seems obvious, but I want to say this explicitly: generic > >>>>>TEE mediator framework should and will use XSM to control which domain > >>>>>can work with TEE. So, if you don't trust your guest - don't let it > >>>>>to call TEE at all. > >>>> > >>>>Correct me if I am wrong. TEE could be used by Android guest which likely > >>>>run the user apps... right? So are you saying you fully trust that guest and > >>>>obviously the user installing rogue app? > >>>I don't think that app downloaded from Play Marget can access OP-TEE directly. > >>>OP-TEE can be used by Android itself as a key storage or to access to a SE, > >>>for example. But 3rd app that issues TEE calls... I don't think so. > >> > >>You didn't get my point here. That rogue app may be able to break into > >>kernel via an exploit or have enough privilege to break the guest. Who knows > >>what it will be able to do after... > >Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed > >to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide > >some safer environment for sensitive data and code. This environment has > >well-defined interfaces and is desgined to be as safe as possible. > > > >If rogue app breaks into kernel, then it can issue any SMC which it wants. > >But OP-TEE does not trust to NW. Hypervisor does not trust to guests. > >Mediator should be written in the same way. > > > >So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is > >known issue. If there is a security bug in OP-TEE, it probably can overcome > >whole system. But this is true for any system running OP-TEE. > > I agree that if you take over OP-TEE, you will take over any system. This is > not specific to hypervisor. Yes. But it just occured to me that mediator+OP-TEE *can* be more secure then just OP-TEE. You see, mediator should perform own security checks before forwarding call to OP-TEE. So if OP-TEE misses something, mediator can back it up. I wouldn't rely on this. It just interesting thought :-) > Baremetal OS taking down the platform will only harm itself. A guest OS > could harm the whole platform. Can't argument with that. I think that this feature (shared TEE) is not suitable for, say, VPSes. But it can work just fine on smartphones or on another embedded devices, where vendor defines whole system. > What I am not sure yet, maybe because of my lack of knowledge around OP-TEE, > who is going to protect a TA to access all the NS memory? TAs is runing in S-EL0. It can't control MMU. Before every TA invocation, OP-TEE setups MMU in such way, so TA sees only shared memory arguments passed by client for this particular invocation. > > > >If there is a security flaw in mediator - it can compromise either hypervisor, > >or DomMediator and all TEE-capable guests. Yes, this is a risk. > > > >>The whole point of using an hypervisor is to isolate guest from each other. > >>So what is the isolation model with OP-TEE and the mediator? > >OP-TEE is written to isolate TAs, resources and clients from each other. > >Currently there are no plans for interaction between TAs from different VMs, > >no resource sharing, nothing like this. > >What do you mean under "isolation model"? Can you give some example? > > By that I meant, who is going to prevent guest A to access guest B data. I > think you partly answered to my question by the "OP-TEE is written to > isolate TAs". The access to NS memory question above will fill the rest I > think. Yes. Every TA is running in own context, and there are no trust even between TAs. > > > >>> > >>>>>This feature is not implemented in this RFC only because > >>>>>currently only Dom0 calls are supported. > >>>>> > >>>>>>This would help to understand that maybe it is an easy way but also still > >>>>>>secure... > >>>>>In previous discussion we considered only two variants: in XEN or outside > >>>>>XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. > >>>>>Such stubdomain will need access to all guests memory. If you managed to > >>>>>gain control on mediator stubdomain, you can do anything you want with all > >>>>>guests. > >>>> > >>>>That's slightly untrue. The stubdomain will only be able to mess with > >>>>domains using TEE. > >>>Yes, this is more strict. Then either you are not allowing your privileged > >>>domain to use TEE, or your system may be compromised anyways. > >> > >>Can you give an example of privilege domain for you? Do you consider Android > >>a privilege domain? > >In this case I used term "priviliged domain" in XEN meaning: is_privileged == 1. > >Android is not privileged domain, by all means. > >I wanted to say that you if you allow Dom0 to access TEE, then hacked DomMediator > >can compromise Dom0 and the hypervisor. > > And I never disagreed in that. This is the non-controversial part :). > > > > >>>>> > >>>>>>To be clear, this series don't look controversial at least for OP-TEE. What > >>>>>>I am more concerned is about DomU supports. > >>>>>Your concern is that rogue DomU can compromise whole system, right? > >>>> > >>>>Yes. You seem to assume that DomU using TEE will always be trusted, I think > >>>>this is the wrong approach if the use is able to interact directly with > >>>>those guests. See above. > >>>No, I am not assuming that DomU that calls TEE should be trusted. Why do you > >>>think so? It should be able to use TEE services, but this does not mean that > >>>XEN should trust it. > >> > >>In a previous answer you said: "So, if you don't trust your guest - don't > >>let it". For me, this clearly means you consider that DomU using TEE are > >>trusted. > >> > >>So can you clarify by what you mean by trust then? > >Well... In real world "trust" isn't binary option. You don't want to > >allow all domains to access TEE. Breached TEE user domain doesn't > >automatically mean that your whole system is compromised. But this > >certainly increases attack surface. So it is safer to give TEE access > >only to those domains, which really require it. You can call them > >sligtly more trusted, then others. > > Do you have an example of guest you would slightly trust more? I have an example of guest I would trust less: if I'm running server, and I'm selling virtual machines on that server, I don't want to them to access TEE. I will trust slightly more to my own guest. > > > >>>Even now, XEN processes requests from DomUs without > >>>trusting them. Why do you think, that TEE mediator usage will differ? > >> > >>I guess you are comparing with vGIC and PL011? IHMO, the main difference is > >>Xen is taking care alone of the isolation between guest. Here in the TEE > >>case, you rely on a combination of both TEE and Xen to do the isolation. > >Yes. This is will be less secure, than TEE-only or hypervisor-only system. > > Can you expand here? If TEE has one security flaw and hypervisor has one security flaw, then you have two security flaws in your system. And any of them can compromise whole system. > > > >>> > >>>Look, I generally not against idea of TEE mediator in stubdoms. But this > >>>approach require many changes in existing XEN code: > >>> > >>>1. Load domains before Dom0. > >>> > >>>2. Add special API for mediator. Or alter existing ones. You can't use > >>> existing APIs as it, because you need to enforce stricter XSM rules > >>> on them. > >> > >>Mind giving more explanation....? Xen has a default policy for XSM and > >>indeed may not fit your use case. But you can write your own policy and load > >>it. > >Yes. You need policy "allow this stubdom to map memory only from TEE-enabled > >guests". AFAIK, this is not possible right now. But I can be wrong, I'm > >not very familiar with XSM. > > I believe XSM could do that. IIRC, you can "label" your domain and use that > to say "stubdom is allowed to access memory with domain using the given > label". Aha. This is good news. Thanks. Looks like I need to dig deeper into XSM... > > > >>> > >>>3. Changes in scheduling to allow TEE mediator use credits/slices of > >>> calling guest. > >>> > >>>4. Support boilerplate code in stubdom. You know, you can't simply > >>> write mediator in stubdom. You need a kernel. You need to > >>> maintain it. > >> > >>Well, in a way or another someone will have to maintain the mediator... The > >>kernel does not need to be specific to TEE, it could be a unikernel. > >Right. But for me XEN looks better maintained "kernel" :) > >IMHO, XEN is mature, there are less bugs (especially security ones) > >than in any other kernel. > > > >>And before you say again no-one in the community seem to be interested. I > >>should remind you that Arm is working on it (see development update). > >You are talking about that "unicore" project by NEC guys? Sorry, > >can't find mentioned development update. Looks like search on markmail > >is down (or I'm doing something terribly wrong). > > Sorry, I meant Mini-OS. I don't know any work on "unicore" for Arm64 for > now. Ah, good to hear. So there will be active maintainer for ARM64 Mini-OS? Sorry, still can't find that "development update". > > > >>> > >>>This is a lot of a work. It requires changes in generic parts of XEN. > >>>I fear it will be very hard to upstream such changes, because no one > >>>sees an immediate value in them. How do you think, what are my chances > >>>to upstream this? > >> > >>It is fairly annoying to see you justifying back most of this thread with > >>"no one sees an immediate value in them". > >> > >>I am not the only maintainers in Xen, so effectively can't promise whether > >>it is going to be upstreamed. But I believe the community has been very > >>supportive so far, a lot of discussions happened (see [2]) because of the > >>OP-TEE support. So what more do you expect from us? > >I'm sorry, I didn't mean to offend you or someone else. You, guys, can > >be harsh sometimes, but I really appreciate help provided by the > >community. And I, certainly, don't ask you about any guarantees or > >something of that sort. > > > >I'm just bothered by amount of required work and by upstreaming > >process. But this is not a strong argument against mediators in > >stubdoms, I think :) > > > >Currently I'm developing virtualization support in OP-TEE, so in > >meantime we'll have much time to discuss mediators and stubdomain > >approach (if you have time). To test this feature in OP-TEE I'm > >extending this RFC, making optee.c to look like full-scale mediator. > >I need to do this anyways, to test OP-TEE. When I'll finish, I can > >show you how mediator can look like. Maybe this will persuade you to > >one or another approach. > > I think this would be useful. Can you also keep both Stefano (I assume he > wants too) and I in the loop for the OP-TEE virtualization side? Okay. I'm planning to produce first RFC for OP-TEE folks in a few days. I'll subscribe you. In then meantime you can check out [2] [1] http://markmail.org/message/tdbg5mgxjvsoj2ph [2] https://github.com/OP-TEE/optee_os/issues/1890 -- WBR, Volodymyr Babchuk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-10-24 19:02 ` Volodymyr Babchuk @ 2017-11-02 13:17 ` Julien Grall 2017-11-02 16:53 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-11-02 13:17 UTC (permalink / raw) To: Volodymyr Babchuk, jens.wiklander Cc: Julien Grall, nd, Stefano Stabellini, xen-devel Hi Volodymyr, On 24/10/17 20:02, Volodymyr Babchuk wrote: >>>>>> If it is not safe, this means you have a whitelist solution and therefore >>>>>> tie Xen to a specific OP-TEE version. So if you need to use a new function >>>>>> you would need to upgrade Xen making the code of using new version >>>>>> potentially high. >>>>> Yes, any ABI change between OP-TEE and its clients will require mediator >>>>> upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll >>>>> install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, >>>>> which is known to XEN. >>>>> >>>>>> Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you >>>>>> impose anyone wanted to modify OP-TEE for their own purpose can make a >>>>>> closed version of the TEE. But if you need to introspect/whitelist call, you >>>>>> impose the vendor to expose their API. >>>>> Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. >>>>> If vendor modifies interface between OP-TEE and Linux, they anyways obligued >>>>> to expose API. >>>> >>>> Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. >>>> >>>> My understanding is the OP-TEE will provide a generic way to access >>>> different Trusted Application. While OP-TEE API may be generic, the TA API >>>> is custom. AFAICT the latter is not part of Linux driver. >>> Yes, you are perfectly right there. >>> >>>> So here my questions: >>>> 1) Are you planning allow all the guests to access every Trusted >>>> Applications? >>> This is a good question. There are two types of TAs supported in >>> OP-TEE: real TAs (as they are described in GlobalPlatform specs) and >>> PseudoTAs. The latter ones are statically linked right into OP-TEE >>> kernel and execute at S-EL1 level. >>> Real TAs are provided by client. That means that NW userspace >>> supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA >>> and then runs it in S-EL0. >>> So, I'm planning to allow client to work with any real TA. I can't see >>> real problem there. >> >> Are the real TAs going to be shared between guests? Or will each guest have >> their own one? > No, we don't plan this. At least at this momoent. Every guest will have > own instance of TA. > >> Will you allow every guests loading real TAs? > Yes, if guest has access to TEE, it can load TA. Either there is no > sense to use TEE. OP-TEE core itself does not provide useful services > to clients. In a previous e-mail you mentioned OP-TEE has limited memory. How will you ensure that guest A will not use all the memory of OP-TEE and prevent guest B to load TAs? [...] >> Not really, you could the domain could block when issuing an SMC until the >> mediator is up and running. > Do you mean, that if domain tries to execute SMC, and mediator is not > ready, then hypervisor should pause all domain's vCPUs? That can be > destructive for hw domain. Xen is free to unschedule any vCPU at any time. So why would it be destructive? [...] >>>>>>> And yes, it seems obvious, but I want to say this explicitly: generic >>>>>>> TEE mediator framework should and will use XSM to control which domain >>>>>>> can work with TEE. So, if you don't trust your guest - don't let it >>>>>>> to call TEE at all. >>>>>> >>>>>> Correct me if I am wrong. TEE could be used by Android guest which likely >>>>>> run the user apps... right? So are you saying you fully trust that guest and >>>>>> obviously the user installing rogue app? >>>>> I don't think that app downloaded from Play Marget can access OP-TEE directly. >>>>> OP-TEE can be used by Android itself as a key storage or to access to a SE, >>>>> for example. But 3rd app that issues TEE calls... I don't think so. >>>> >>>> You didn't get my point here. That rogue app may be able to break into >>>> kernel via an exploit or have enough privilege to break the guest. Who knows >>>> what it will be able to do after... >>> Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed >>> to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide >>> some safer environment for sensitive data and code. This environment has >>> well-defined interfaces and is desgined to be as safe as possible. >>> >>> If rogue app breaks into kernel, then it can issue any SMC which it wants. >>> But OP-TEE does not trust to NW. Hypervisor does not trust to guests. >>> Mediator should be written in the same way. >>> >>> So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is >>> known issue. If there is a security bug in OP-TEE, it probably can overcome >>> whole system. But this is true for any system running OP-TEE. >> >> I agree that if you take over OP-TEE, you will take over any system. This is >> not specific to hypervisor. > Yes. But it just occured to me that mediator+OP-TEE *can* be more > secure then just OP-TEE. You see, mediator should perform own security > checks before forwarding call to OP-TEE. So if OP-TEE misses > something, mediator can back it up. I wouldn't rely on this. It just > interesting thought :-) > >> Baremetal OS taking down the platform will only harm itself. A guest OS >> could harm the whole platform. > Can't argument with that. I think that this feature (shared TEE) is > not suitable for, say, VPSes. But it can work just fine on smartphones > or on another embedded devices, where vendor defines whole system. I guess your use case is "vendor defines whole system". But I am struggling understand how this would more suitable there. That guest OS may be "controlled" by the user. So how is that safer? > >> What I am not sure yet, maybe because of my lack of knowledge around OP-TEE, >> who is going to protect a TA to access all the NS memory? > TAs is runing in S-EL0. It can't control MMU. Before every TA > invocation, OP-TEE setups MMU in such way, so TA sees only shared > memory arguments passed by client for this particular invocation. Can you give a bit more details here? Particularly what is the life of that mapped region? Is it just for a command? If not, who is going to unmap it and when? > >>> >>> If there is a security flaw in mediator - it can compromise either hypervisor, >>> or DomMediator and all TEE-capable guests. Yes, this is a risk. >>> >>>> The whole point of using an hypervisor is to isolate guest from each other. >>>> So what is the isolation model with OP-TEE and the mediator? >>> OP-TEE is written to isolate TAs, resources and clients from each other. >>> Currently there are no plans for interaction between TAs from different VMs, >>> no resource sharing, nothing like this. >>> What do you mean under "isolation model"? Can you give some example? >> >> By that I meant, who is going to prevent guest A to access guest B data. I >> think you partly answered to my question by the "OP-TEE is written to >> isolate TAs". The access to NS memory question above will fill the rest I >> think. > Yes. Every TA is running in own context, and there are no trust even > between TAs. Glad to hear that. [...] >>>>>>>> To be clear, this series don't look controversial at least for OP-TEE. What >>>>>>>> I am more concerned is about DomU supports. >>>>>>> Your concern is that rogue DomU can compromise whole system, right? >>>>>> >>>>>> Yes. You seem to assume that DomU using TEE will always be trusted, I think >>>>>> this is the wrong approach if the use is able to interact directly with >>>>>> those guests. See above. >>>>> No, I am not assuming that DomU that calls TEE should be trusted. Why do you >>>>> think so? It should be able to use TEE services, but this does not mean that >>>>> XEN should trust it. >>>> >>>> In a previous answer you said: "So, if you don't trust your guest - don't >>>> let it". For me, this clearly means you consider that DomU using TEE are >>>> trusted. >>>> >>>> So can you clarify by what you mean by trust then? >>> Well... In real world "trust" isn't binary option. You don't want to >>> allow all domains to access TEE. Breached TEE user domain doesn't >>> automatically mean that your whole system is compromised. But this >>> certainly increases attack surface. So it is safer to give TEE access >>> only to those domains, which really require it. You can call them >>> sligtly more trusted, then others. >> >> Do you have an example of guest you would slightly trust more? > I have an example of guest I would trust less: if I'm running server, > and I'm selling virtual machines on that server, I don't want to them > to access TEE. Make sense. > > I will trust slightly more to my own guest. I kind of agree if there are either no interaction with the user or the user is not able to gain privilege permissions. > >>> >>>>> Even now, XEN processes requests from DomUs without >>>>> trusting them. Why do you think, that TEE mediator usage will differ? >>>> >>>> I guess you are comparing with vGIC and PL011? IHMO, the main difference is >>>> Xen is taking care alone of the isolation between guest. Here in the TEE >>>> case, you rely on a combination of both TEE and Xen to do the isolation. >>> Yes. This is will be less secure, than TEE-only or hypervisor-only system. >> >> Can you expand here? > If TEE has one security flaw and hypervisor has one security flaw, > then you have two security flaws in your system. And any of them can > compromise whole system. Make sense. >>> >>>>> >>>>> Look, I generally not against idea of TEE mediator in stubdoms. But this >>>>> approach require many changes in existing XEN code: >>>>> >>>>> 1. Load domains before Dom0. >>>>> >>>>> 2. Add special API for mediator. Or alter existing ones. You can't use >>>>> existing APIs as it, because you need to enforce stricter XSM rules >>>>> on them. >>>> >>>> Mind giving more explanation....? Xen has a default policy for XSM and >>>> indeed may not fit your use case. But you can write your own policy and load >>>> it. >>> Yes. You need policy "allow this stubdom to map memory only from TEE-enabled >>> guests". AFAIK, this is not possible right now. But I can be wrong, I'm >>> not very familiar with XSM. >> >> I believe XSM could do that. IIRC, you can "label" your domain and use that >> to say "stubdom is allowed to access memory with domain using the given >> label". > Aha. This is good news. Thanks. Looks like I need to dig deeper into XSM... > >>> >>>>> >>>>> 3. Changes in scheduling to allow TEE mediator use credits/slices of >>>>> calling guest. >>>>> >>>>> 4. Support boilerplate code in stubdom. You know, you can't simply >>>>> write mediator in stubdom. You need a kernel. You need to >>>>> maintain it. >>>> >>>> Well, in a way or another someone will have to maintain the mediator... The >>>> kernel does not need to be specific to TEE, it could be a unikernel. >>> Right. But for me XEN looks better maintained "kernel" :) >>> IMHO, XEN is mature, there are less bugs (especially security ones) >>> than in any other kernel. >>> >>>> And before you say again no-one in the community seem to be interested. I >>>> should remind you that Arm is working on it (see development update). >>> You are talking about that "unicore" project by NEC guys? Sorry, >>> can't find mentioned development update. Looks like search on markmail >>> is down (or I'm doing something terribly wrong). >> >> Sorry, I meant Mini-OS. I don't know any work on "unicore" for Arm64 for >> now. > Ah, good to hear. So there will be active maintainer for ARM64 > Mini-OS? Sorry, still can't find that "development update". At the moment, the series is still in development. But yet the plan is to get Arm64 fully supported in Mini-OS. > >>> >>>>> >>>>> This is a lot of a work. It requires changes in generic parts of XEN. >>>>> I fear it will be very hard to upstream such changes, because no one >>>>> sees an immediate value in them. How do you think, what are my chances >>>>> to upstream this? >>>> >>>> It is fairly annoying to see you justifying back most of this thread with >>>> "no one sees an immediate value in them". >>>> >>>> I am not the only maintainers in Xen, so effectively can't promise whether >>>> it is going to be upstreamed. But I believe the community has been very >>>> supportive so far, a lot of discussions happened (see [2]) because of the >>>> OP-TEE support. So what more do you expect from us? >>> I'm sorry, I didn't mean to offend you or someone else. You, guys, can >>> be harsh sometimes, but I really appreciate help provided by the >>> community. And I, certainly, don't ask you about any guarantees or >>> something of that sort. >>> >>> I'm just bothered by amount of required work and by upstreaming >>> process. But this is not a strong argument against mediators in >>> stubdoms, I think :) >>> >>> Currently I'm developing virtualization support in OP-TEE, so in >>> meantime we'll have much time to discuss mediators and stubdomain >>> approach (if you have time). To test this feature in OP-TEE I'm >>> extending this RFC, making optee.c to look like full-scale mediator. >>> I need to do this anyways, to test OP-TEE. When I'll finish, I can >>> show you how mediator can look like. Maybe this will persuade you to >>> one or another approach. >> >> I think this would be useful. Can you also keep both Stefano (I assume he >> wants too) and I in the loop for the OP-TEE virtualization side? > Okay. I'm planning to produce first RFC for OP-TEE folks in a few > days. I'll subscribe you. In then meantime you can check out [2] Thank you! > [1] http://markmail.org/message/tdbg5mgxjvsoj2ph > [2] https://github.com/OP-TEE/optee_os/issues/1890 Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-11-02 13:17 ` Julien Grall @ 2017-11-02 16:53 ` Volodymyr Babchuk 2017-11-02 17:49 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-11-02 16:53 UTC (permalink / raw) To: Julien Grall Cc: Julien Grall, nd, Stefano Stabellini, jens.wiklander, xen-devel On Thu, Nov 02, 2017 at 01:17:26PM +0000, Julien Grall wrote: Hi Julien, > On 24/10/17 20:02, Volodymyr Babchuk wrote: > >>>>>>If it is not safe, this means you have a whitelist solution and therefore > >>>>>>tie Xen to a specific OP-TEE version. So if you need to use a new function > >>>>>>you would need to upgrade Xen making the code of using new version > >>>>>>potentially high. > >>>>>Yes, any ABI change between OP-TEE and its clients will require mediator > >>>>>upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll > >>>>>install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, > >>>>>which is known to XEN. > >>>>> > >>>>>>Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you > >>>>>>impose anyone wanted to modify OP-TEE for their own purpose can make a > >>>>>>closed version of the TEE. But if you need to introspect/whitelist call, you > >>>>>>impose the vendor to expose their API. > >>>>>Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. > >>>>>If vendor modifies interface between OP-TEE and Linux, they anyways obligued > >>>>>to expose API. > >>>> > >>>>Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. > >>>> > >>>>My understanding is the OP-TEE will provide a generic way to access > >>>>different Trusted Application. While OP-TEE API may be generic, the TA API > >>>>is custom. AFAICT the latter is not part of Linux driver. > >>>Yes, you are perfectly right there. > >>> > >>>>So here my questions: > >>>> 1) Are you planning allow all the guests to access every Trusted > >>>>Applications? > >>>This is a good question. There are two types of TAs supported in > >>>OP-TEE: real TAs (as they are described in GlobalPlatform specs) and > >>>PseudoTAs. The latter ones are statically linked right into OP-TEE > >>>kernel and execute at S-EL1 level. > >>>Real TAs are provided by client. That means that NW userspace > >>>supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA > >>>and then runs it in S-EL0. > >>>So, I'm planning to allow client to work with any real TA. I can't see > >>>real problem there. > >> > >>Are the real TAs going to be shared between guests? Or will each guest have > >>their own one? > >No, we don't plan this. At least at this momoent. Every guest will have > >own instance of TA. > > > >>Will you allow every guests loading real TAs? > >Yes, if guest has access to TEE, it can load TA. Either there is no > >sense to use TEE. OP-TEE core itself does not provide useful services > >to clients. > > In a previous e-mail you mentioned OP-TEE has limited memory. How will you > ensure that guest A will not use all the memory of OP-TEE and prevent guest > B to load TAs? There are no way to do this right now. Even on bare-metal system, one client call load huge TA or eat up memory in another way to prevent other clients to use OP-TEE. This is known limitation. It can be mitigated by enforcing quotas. > [...] > > >>Not really, you could the domain could block when issuing an SMC until the > >>mediator is up and running. > >Do you mean, that if domain tries to execute SMC, and mediator is not > >ready, then hypervisor should pause all domain's vCPUs? That can be > >destructive for hw domain. > > Xen is free to unschedule any vCPU at any time. So why would it be > destructive? Suppose that mediator domain needs 0.5s to boot up and be ready to serve calls. For half of a second HW domain will be blocked. I don't like the idea, that it will not be able to serve IRQs and other requests. IMHO, it is okay for DomU, but not for Dom0. > >>>>>>>And yes, it seems obvious, but I want to say this explicitly: generic > >>>>>>>TEE mediator framework should and will use XSM to control which domain > >>>>>>>can work with TEE. So, if you don't trust your guest - don't let it > >>>>>>>to call TEE at all. > >>>>>> > >>>>>>Correct me if I am wrong. TEE could be used by Android guest which likely > >>>>>>run the user apps... right? So are you saying you fully trust that guest and > >>>>>>obviously the user installing rogue app? > >>>>>I don't think that app downloaded from Play Marget can access OP-TEE directly. > >>>>>OP-TEE can be used by Android itself as a key storage or to access to a SE, > >>>>>for example. But 3rd app that issues TEE calls... I don't think so. > >>>> > >>>>You didn't get my point here. That rogue app may be able to break into > >>>>kernel via an exploit or have enough privilege to break the guest. Who knows > >>>>what it will be able to do after... > >>>Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed > >>>to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide > >>>some safer environment for sensitive data and code. This environment has > >>>well-defined interfaces and is desgined to be as safe as possible. > >>> > >>>If rogue app breaks into kernel, then it can issue any SMC which it wants. > >>>But OP-TEE does not trust to NW. Hypervisor does not trust to guests. > >>>Mediator should be written in the same way. > >>> > >>>So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is > >>>known issue. If there is a security bug in OP-TEE, it probably can overcome > >>>whole system. But this is true for any system running OP-TEE. > >> > >>I agree that if you take over OP-TEE, you will take over any system. This is > >>not specific to hypervisor. > >Yes. But it just occured to me that mediator+OP-TEE *can* be more > >secure then just OP-TEE. You see, mediator should perform own security > >checks before forwarding call to OP-TEE. So if OP-TEE misses > >something, mediator can back it up. I wouldn't rely on this. It just > >interesting thought :-) > > > >>Baremetal OS taking down the platform will only harm itself. A guest OS > >>could harm the whole platform. > >Can't argument with that. I think that this feature (shared TEE) is > >not suitable for, say, VPSes. But it can work just fine on smartphones > >or on another embedded devices, where vendor defines whole system. > > I guess your use case is "vendor defines whole system". But I am struggling > understand how this would more suitable there. Excuse me... "There" - it is where exactly? > That guest OS may be "controlled" by the user. So how is that safer? Can you please define what is "safe" and "unsafe" in this context? Lets take a look at whole picture. I can see the following attacks: 1) DoS attack. One domain spends all OP-TEE resources, other domains can't work with it. As I said earlier, this is know limitation. 2) Mediator crash. Sort of DoS, if mediator can't restart properly. 3) OP-TEE crash. This crashes whole system. 4) Virtualization breach. Attacker gains control over mediator -> control over all TEE-enabled guests. 5) Virtualization breach. Attacker gains control over hypervisor -> control over all guests. 6) Virtualization breach. Attacker gains control over OP-TEE -> control over whole system, including firmware. Now it would be great to give you likehood for every attack type. But, obvioulsy I have no such numbers. I can only speculate about this. Returning to your question... To what extent guest OS can be controlled by user? Can user execute arbitrary code at EL1 for example? Or it can install only apps prebuilt by system vendor? What bad things will happen if user will compromise the whole system? Which guests will also run on the same system? Which subset of them will access OP-TEE? If you can asnwer to this questions, I can tell you, if it is safe to use OP-TEE + virtualization on your system. For some "generic" system I can say that it is pretty "safe" (except that problem with OP-TEE resources). > > > >>What I am not sure yet, maybe because of my lack of knowledge around OP-TEE, > >>who is going to protect a TA to access all the NS memory? > >TAs is runing in S-EL0. It can't control MMU. Before every TA > >invocation, OP-TEE setups MMU in such way, so TA sees only shared > >memory arguments passed by client for this particular invocation. > > Can you give a bit more details here? Particularly what is the life of that > mapped region? Is it just for a command? If not, who is going to unmap it > and when? Yes, this map is created for every call. TA code and data are mapped always, obviously. But parameters are mapped every call and only needed ones. Example: I have shared buffers A, B, C, D. 1) I call OpenSession(TA_UUID, A, B). TA sees only buffers A, B (okay, actually it sees whole page, because buffer is mapped from userspace). 2) I call InvokeCommand(Session, CMD_ID, B, C). TA sees only buffers B & C. 3) I call InvokeCommand(Session, CMD_ID, A, D). TA sees only buffers A & D. Note, that such buffers are not mapped at OP-TEE address space at all. They will be mapped only to TA address space. [...] > >>>>>>>>To be clear, this series don't look controversial at least for OP-TEE. What > >>>>>>>>I am more concerned is about DomU supports. > >>>>>>>Your concern is that rogue DomU can compromise whole system, right? > >>>>>> > >>>>>>Yes. You seem to assume that DomU using TEE will always be trusted, I think > >>>>>>this is the wrong approach if the use is able to interact directly with > >>>>>>those guests. See above. > >>>>>No, I am not assuming that DomU that calls TEE should be trusted. Why do you > >>>>>think so? It should be able to use TEE services, but this does not mean that > >>>>>XEN should trust it. > >>>> > >>>>In a previous answer you said: "So, if you don't trust your guest - don't > >>>>let it". For me, this clearly means you consider that DomU using TEE are > >>>>trusted. > >>>> > >>>>So can you clarify by what you mean by trust then? > >>>Well... In real world "trust" isn't binary option. You don't want to > >>>allow all domains to access TEE. Breached TEE user domain doesn't > >>>automatically mean that your whole system is compromised. But this > >>>certainly increases attack surface. So it is safer to give TEE access > >>>only to those domains, which really require it. You can call them > >>>sligtly more trusted, then others. > >> > >>Do you have an example of guest you would slightly trust more? > >I have an example of guest I would trust less: if I'm running server, > >and I'm selling virtual machines on that server, I don't want to them > >to access TEE. > > Make sense. > > > > >I will trust slightly more to my own guest. > > I kind of agree if there are either no interaction with the user or the user > is not able to gain privilege permissions. Okay, if user can execute arbitrary code at EL1... Even then nothing bad will happen. They must be able to hack mediator/hypervisor/OP-TEE to realy gain priviegs in system. [...] > >>>>>3. Changes in scheduling to allow TEE mediator use credits/slices of > >>>>> calling guest. > >>>>> > >>>>>4. Support boilerplate code in stubdom. You know, you can't simply > >>>>> write mediator in stubdom. You need a kernel. You need to > >>>>> maintain it. > >>>> > >>>>Well, in a way or another someone will have to maintain the mediator... The > >>>>kernel does not need to be specific to TEE, it could be a unikernel. > >>>Right. But for me XEN looks better maintained "kernel" :) > >>>IMHO, XEN is mature, there are less bugs (especially security ones) > >>>than in any other kernel. > >>> > >>>>And before you say again no-one in the community seem to be interested. I > >>>>should remind you that Arm is working on it (see development update). > >>>You are talking about that "unicore" project by NEC guys? Sorry, > >>>can't find mentioned development update. Looks like search on markmail > >>>is down (or I'm doing something terribly wrong). > >> > >>Sorry, I meant Mini-OS. I don't know any work on "unicore" for Arm64 for > >>now. > >Ah, good to hear. So there will be active maintainer for ARM64 > >Mini-OS? Sorry, still can't find that "development update". > > At the moment, the series is still in development. But yet the plan is to > get Arm64 fully supported in Mini-OS. Ah, I see. Thanks. > > > >>> > >>>>> > >>>>>This is a lot of a work. It requires changes in generic parts of XEN. > >>>>>I fear it will be very hard to upstream such changes, because no one > >>>>>sees an immediate value in them. How do you think, what are my chances > >>>>>to upstream this? > >>>> > >>>>It is fairly annoying to see you justifying back most of this thread with > >>>>"no one sees an immediate value in them". > >>>> > >>>>I am not the only maintainers in Xen, so effectively can't promise whether > >>>>it is going to be upstreamed. But I believe the community has been very > >>>>supportive so far, a lot of discussions happened (see [2]) because of the > >>>>OP-TEE support. So what more do you expect from us? > >>>I'm sorry, I didn't mean to offend you or someone else. You, guys, can > >>>be harsh sometimes, but I really appreciate help provided by the > >>>community. And I, certainly, don't ask you about any guarantees or > >>>something of that sort. > >>> > >>>I'm just bothered by amount of required work and by upstreaming > >>>process. But this is not a strong argument against mediators in > >>>stubdoms, I think :) > >>> > >>>Currently I'm developing virtualization support in OP-TEE, so in > >>>meantime we'll have much time to discuss mediators and stubdomain > >>>approach (if you have time). To test this feature in OP-TEE I'm > >>>extending this RFC, making optee.c to look like full-scale mediator. > >>>I need to do this anyways, to test OP-TEE. When I'll finish, I can > >>>show you how mediator can look like. Maybe this will persuade you to > >>>one or another approach. > >> > >>I think this would be useful. Can you also keep both Stefano (I assume he > >>wants too) and I in the loop for the OP-TEE virtualization side? > >Okay. I'm planning to produce first RFC for OP-TEE folks in a few > >days. I'll subscribe you. In then meantime you can check out [2] > > Thank you! Looks like I can't add people to PR. So there is a link: [3] > >[1] http://markmail.org/message/tdbg5mgxjvsoj2ph > >[2] https://github.com/OP-TEE/optee_os/issues/1890 [3] https://github.com/OP-TEE/optee_os/pull/1910 WBR, -- Volodymyr Babchuk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-11-02 16:53 ` Volodymyr Babchuk @ 2017-11-02 17:49 ` Julien Grall 2017-11-02 20:07 ` Volodymyr Babchuk 0 siblings, 1 reply; 44+ messages in thread From: Julien Grall @ 2017-11-02 17:49 UTC (permalink / raw) To: Volodymyr Babchuk Cc: Julien Grall, nd, Stefano Stabellini, jens.wiklander, xen-devel Hi Volodymyr, On 02/11/17 16:53, Volodymyr Babchuk wrote: > On Thu, Nov 02, 2017 at 01:17:26PM +0000, Julien Grall wrote: >> On 24/10/17 20:02, Volodymyr Babchuk wrote: >>>>>>>> If it is not safe, this means you have a whitelist solution and therefore >>>>>>>> tie Xen to a specific OP-TEE version. So if you need to use a new function >>>>>>>> you would need to upgrade Xen making the code of using new version >>>>>>>> potentially high. >>>>>>> Yes, any ABI change between OP-TEE and its clients will require mediator >>>>>>> upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll >>>>>>> install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, >>>>>>> which is known to XEN. >>>>>>> >>>>>>>> Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you >>>>>>>> impose anyone wanted to modify OP-TEE for their own purpose can make a >>>>>>>> closed version of the TEE. But if you need to introspect/whitelist call, you >>>>>>>> impose the vendor to expose their API. >>>>>>> Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. >>>>>>> If vendor modifies interface between OP-TEE and Linux, they anyways obligued >>>>>>> to expose API. >>>>>> >>>>>> Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. >>>>>> >>>>>> My understanding is the OP-TEE will provide a generic way to access >>>>>> different Trusted Application. While OP-TEE API may be generic, the TA API >>>>>> is custom. AFAICT the latter is not part of Linux driver. >>>>> Yes, you are perfectly right there. >>>>> >>>>>> So here my questions: >>>>>> 1) Are you planning allow all the guests to access every Trusted >>>>>> Applications? >>>>> This is a good question. There are two types of TAs supported in >>>>> OP-TEE: real TAs (as they are described in GlobalPlatform specs) and >>>>> PseudoTAs. The latter ones are statically linked right into OP-TEE >>>>> kernel and execute at S-EL1 level. >>>>> Real TAs are provided by client. That means that NW userspace >>>>> supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA >>>>> and then runs it in S-EL0. >>>>> So, I'm planning to allow client to work with any real TA. I can't see >>>>> real problem there. >>>> >>>> Are the real TAs going to be shared between guests? Or will each guest have >>>> their own one? >>> No, we don't plan this. At least at this momoent. Every guest will have >>> own instance of TA. >>> >>>> Will you allow every guests loading real TAs? >>> Yes, if guest has access to TEE, it can load TA. Either there is no >>> sense to use TEE. OP-TEE core itself does not provide useful services >>> to clients. >> >> In a previous e-mail you mentioned OP-TEE has limited memory. How will you >> ensure that guest A will not use all the memory of OP-TEE and prevent guest >> B to load TAs? > There are no way to do this right now. Even on bare-metal system, one client > call load huge TA or eat up memory in another way to prevent other clients > to use OP-TEE. This is known limitation. It can be mitigated by enforcing > quotas. Yes, but those clients only serve one OS. Here you would serve multiple OSes, clients from OS A could eat up the memory and prevent a client from OS B to run. This could be a serious issue depending on how important the clients for OS are. So likely enforcing quotas will be needed. > >> [...] >> >>>> Not really, you could the domain could block when issuing an SMC until the >>>> mediator is up and running. >>> Do you mean, that if domain tries to execute SMC, and mediator is not >>> ready, then hypervisor should pause all domain's vCPUs? That can be >>> destructive for hw domain. >> >> Xen is free to unschedule any vCPU at any time. So why would it be >> destructive? > Suppose that mediator domain needs 0.5s to boot up and be ready to > serve calls. For half of a second HW domain will be blocked. I don't > like the idea, that it will not be able to serve IRQs and other > requests. IMHO, it is okay for DomU, but not for Dom0. > >>>>>>>>> And yes, it seems obvious, but I want to say this explicitly: generic >>>>>>>>> TEE mediator framework should and will use XSM to control which domain >>>>>>>>> can work with TEE. So, if you don't trust your guest - don't let it >>>>>>>>> to call TEE at all. >>>>>>>> >>>>>>>> Correct me if I am wrong. TEE could be used by Android guest which likely >>>>>>>> run the user apps... right? So are you saying you fully trust that guest and >>>>>>>> obviously the user installing rogue app? >>>>>>> I don't think that app downloaded from Play Marget can access OP-TEE directly. >>>>>>> OP-TEE can be used by Android itself as a key storage or to access to a SE, >>>>>>> for example. But 3rd app that issues TEE calls... I don't think so. >>>>>> >>>>>> You didn't get my point here. That rogue app may be able to break into >>>>>> kernel via an exploit or have enough privilege to break the guest. Who knows >>>>>> what it will be able to do after... >>>>> Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed >>>>> to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide >>>>> some safer environment for sensitive data and code. This environment has >>>>> well-defined interfaces and is desgined to be as safe as possible. >>>>> >>>>> If rogue app breaks into kernel, then it can issue any SMC which it wants. >>>>> But OP-TEE does not trust to NW. Hypervisor does not trust to guests. >>>>> Mediator should be written in the same way. >>>>> >>>>> So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is >>>>> known issue. If there is a security bug in OP-TEE, it probably can overcome >>>>> whole system. But this is true for any system running OP-TEE. >>>> >>>> I agree that if you take over OP-TEE, you will take over any system. This is >>>> not specific to hypervisor. >>> Yes. But it just occured to me that mediator+OP-TEE *can* be more >>> secure then just OP-TEE. You see, mediator should perform own security >>> checks before forwarding call to OP-TEE. So if OP-TEE misses >>> something, mediator can back it up. I wouldn't rely on this. It just >>> interesting thought :-) >>> >>>> Baremetal OS taking down the platform will only harm itself. A guest OS >>>> could harm the whole platform. >>> Can't argument with that. I think that this feature (shared TEE) is >>> not suitable for, say, VPSes. But it can work just fine on smartphones >>> or on another embedded devices, where vendor defines whole system. >> >> I guess your use case is "vendor defines whole system". But I am struggling >> understand how this would more suitable there. > Excuse me... "There" - it is where exactly? "vendor defines whole system". > >> That guest OS may be "controlled" by the user. So how is that safer? > Can you please define what is "safe" and "unsafe" in this context? > > Lets take a look at whole picture. I can see the following attacks: > > 1) DoS attack. One domain spends all OP-TEE resources, other domains > can't work with it. As I said earlier, this is know limitation. > > 2) Mediator crash. Sort of DoS, if mediator can't restart properly. > > 3) OP-TEE crash. This crashes whole system. > > 4) Virtualization breach. Attacker gains control over mediator -> > control over all TEE-enabled guests. > > 5) Virtualization breach. Attacker gains control over hypervisor -> > control over all guests. > > 6) Virtualization breach. Attacker gains control over OP-TEE -> > control over whole system, including firmware. > > Now it would be great to give you likehood for every attack type. But, > obvioulsy I have no such numbers. I can only speculate about this. > > Returning to your question... To what extent guest OS can be controlled > by user? Can user execute arbitrary code at EL1 for example? Or it can > install only apps prebuilt by system vendor? > > What bad things will happen if user will compromise the whole system? > > Which guests will also run on the same system? Which subset of them > will access OP-TEE? > > If you can asnwer to this questions, I can tell you, if it is safe > to use OP-TEE + virtualization on your system. I don't make any end product and I have no idea what kind of guests would be run on top. So if I had to answers to those questions, I would consider all the guests potentially nasty and therefore making sure the attack surface is limited and understood. You really have to ask yourself what kinds of guest you will run on that platform and assess the risk. If you tell me you are going to run safety critical in one VM and another with Android. Then I would be looking at limiting the attack surface of the Android guest. If you tell me that the user will only be able to install pre-built apps by system vendor. Then I will have some trouble to believe it is secure given how complex is an operating system. And I am not even mentioning that allowing the user to install pre-built apps by system vendor likely means having network/bluetooth access. I am sure you have seen recently vulnerability... > > For some "generic" system I can say that it is pretty "safe" (except > that problem with OP-TEE resources). > >>> >>>> What I am not sure yet, maybe because of my lack of knowledge around OP-TEE, >>>> who is going to protect a TA to access all the NS memory? >>> TAs is runing in S-EL0. It can't control MMU. Before every TA >>> invocation, OP-TEE setups MMU in such way, so TA sees only shared >>> memory arguments passed by client for this particular invocation. >> >> Can you give a bit more details here? Particularly what is the life of that >> mapped region? Is it just for a command? If not, who is going to unmap it >> and when? > Yes, this map is created for every call. TA code and data are mapped always, > obviously. Where does the TA code and data live? Is it in secure or non-secure memory? > But parameters are mapped every call and only needed ones. > Example: I have shared buffers A, B, C, D. > > 1) I call OpenSession(TA_UUID, A, B). > TA sees only buffers A, B (okay, actually it sees whole page, because > buffer is mapped from userspace). > > 2) I call InvokeCommand(Session, CMD_ID, B, C). > TA sees only buffers B & C. > > 3) I call InvokeCommand(Session, CMD_ID, A, D). > TA sees only buffers A & D. > > Note, that such buffers are not mapped at OP-TEE address space at all. > They will be mapped only to TA address space. To confirm, what you are saying is as soon as any call is returned by TA, the region will be unmapped from the TA address space? > > [...] >>>>>>>>>> To be clear, this series don't look controversial at least for OP-TEE. What >>>>>>>>>> I am more concerned is about DomU supports. >>>>>>>>> Your concern is that rogue DomU can compromise whole system, right? >>>>>>>> >>>>>>>> Yes. You seem to assume that DomU using TEE will always be trusted, I think >>>>>>>> this is the wrong approach if the use is able to interact directly with >>>>>>>> those guests. See above. >>>>>>> No, I am not assuming that DomU that calls TEE should be trusted. Why do you >>>>>>> think so? It should be able to use TEE services, but this does not mean that >>>>>>> XEN should trust it. >>>>>> >>>>>> In a previous answer you said: "So, if you don't trust your guest - don't >>>>>> let it". For me, this clearly means you consider that DomU using TEE are >>>>>> trusted. >>>>>> >>>>>> So can you clarify by what you mean by trust then? >>>>> Well... In real world "trust" isn't binary option. You don't want to >>>>> allow all domains to access TEE. Breached TEE user domain doesn't >>>>> automatically mean that your whole system is compromised. But this >>>>> certainly increases attack surface. So it is safer to give TEE access >>>>> only to those domains, which really require it. You can call them >>>>> sligtly more trusted, then others. >>>> >>>> Do you have an example of guest you would slightly trust more? >>> I have an example of guest I would trust less: if I'm running server, >>> and I'm selling virtual machines on that server, I don't want to them >>> to access TEE. >> >> Make sense. >> >>> >>> I will trust slightly more to my own guest. >> >> I kind of agree if there are either no interaction with the user or the user >> is not able to gain privilege permissions. > Okay, if user can execute arbitrary code at EL1... Even then nothing bad > will happen. They must be able to hack mediator/hypervisor/OP-TEE to realy > gain priviegs in system. My worry here is you base the trust on OP-TEE and not only the hypervisor. At the moment we had to trust the hardware to do the right thing and the software is owned by Xen. Now you are telling me, we have this TEE running in EL3 and have to trust him to do the isolation between guests. Until the last 2 e-mails, it was not clear for me how OP-TEE could ensure this isolation. I would advise to explain a bit more in your cover letter of your next version the design of OP-TEE. This would help people to see how this can work with the hypervisor and also understanding the consequence... Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-11-02 17:49 ` Julien Grall @ 2017-11-02 20:07 ` Volodymyr Babchuk 2017-11-07 16:03 ` Julien Grall 0 siblings, 1 reply; 44+ messages in thread From: Volodymyr Babchuk @ 2017-11-02 20:07 UTC (permalink / raw) To: Julien Grall Cc: Julien Grall, nd, Stefano Stabellini, jens.wiklander, xen-devel On Thu, Nov 02, 2017 at 05:49:12PM +0000, Julien Grall wrote: Hi Julien, > On 02/11/17 16:53, Volodymyr Babchuk wrote: > >On Thu, Nov 02, 2017 at 01:17:26PM +0000, Julien Grall wrote: > >>On 24/10/17 20:02, Volodymyr Babchuk wrote: > >>>>>>>>If it is not safe, this means you have a whitelist solution and therefore > >>>>>>>>tie Xen to a specific OP-TEE version. So if you need to use a new function > >>>>>>>>you would need to upgrade Xen making the code of using new version > >>>>>>>>potentially high. > >>>>>>>Yes, any ABI change between OP-TEE and its clients will require mediator > >>>>>>>upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll > >>>>>>>install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, > >>>>>>>which is known to XEN. > >>>>>>> > >>>>>>>>Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you > >>>>>>>>impose anyone wanted to modify OP-TEE for their own purpose can make a > >>>>>>>>closed version of the TEE. But if you need to introspect/whitelist call, you > >>>>>>>>impose the vendor to expose their API. > >>>>>>>Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. > >>>>>>>If vendor modifies interface between OP-TEE and Linux, they anyways obligued > >>>>>>>to expose API. > >>>>>> > >>>>>>Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. > >>>>>> > >>>>>>My understanding is the OP-TEE will provide a generic way to access > >>>>>>different Trusted Application. While OP-TEE API may be generic, the TA API > >>>>>>is custom. AFAICT the latter is not part of Linux driver. > >>>>>Yes, you are perfectly right there. > >>>>> > >>>>>>So here my questions: > >>>>>> 1) Are you planning allow all the guests to access every Trusted > >>>>>>Applications? > >>>>>This is a good question. There are two types of TAs supported in > >>>>>OP-TEE: real TAs (as they are described in GlobalPlatform specs) and > >>>>>PseudoTAs. The latter ones are statically linked right into OP-TEE > >>>>>kernel and execute at S-EL1 level. > >>>>>Real TAs are provided by client. That means that NW userspace > >>>>>supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA > >>>>>and then runs it in S-EL0. > >>>>>So, I'm planning to allow client to work with any real TA. I can't see > >>>>>real problem there. > >>>> > >>>>Are the real TAs going to be shared between guests? Or will each guest have > >>>>their own one? > >>>No, we don't plan this. At least at this momoent. Every guest will have > >>>own instance of TA. > >>> > >>>>Will you allow every guests loading real TAs? > >>>Yes, if guest has access to TEE, it can load TA. Either there is no > >>>sense to use TEE. OP-TEE core itself does not provide useful services > >>>to clients. > >> > >>In a previous e-mail you mentioned OP-TEE has limited memory. How will you > >>ensure that guest A will not use all the memory of OP-TEE and prevent guest > >>B to load TAs? > >There are no way to do this right now. Even on bare-metal system, one client > >call load huge TA or eat up memory in another way to prevent other clients > >to use OP-TEE. This is known limitation. It can be mitigated by enforcing > >quotas. > > Yes, but those clients only serve one OS. Here you would serve multiple > OSes, clients from OS A could eat up the memory and prevent a client from OS > B to run. > > This could be a serious issue depending on how important the clients for OS > are. > > So likely enforcing quotas will be needed. Yes. I agree there. I think, it is possible to implement them in mediator, so we can use XSM to define quotas. > > > >>[...] > >> > >>>>Not really, you could the domain could block when issuing an SMC until the > >>>>mediator is up and running. > >>>Do you mean, that if domain tries to execute SMC, and mediator is not > >>>ready, then hypervisor should pause all domain's vCPUs? That can be > >>>destructive for hw domain. > >> > >>Xen is free to unschedule any vCPU at any time. So why would it be > >>destructive? > >Suppose that mediator domain needs 0.5s to boot up and be ready to > >serve calls. For half of a second HW domain will be blocked. I don't > >like the idea, that it will not be able to serve IRQs and other > >requests. IMHO, it is okay for DomU, but not for Dom0. > > > > > >>>>>>>>>And yes, it seems obvious, but I want to say this explicitly: generic > >>>>>>>>>TEE mediator framework should and will use XSM to control which domain > >>>>>>>>>can work with TEE. So, if you don't trust your guest - don't let it > >>>>>>>>>to call TEE at all. > >>>>>>>> > >>>>>>>>Correct me if I am wrong. TEE could be used by Android guest which likely > >>>>>>>>run the user apps... right? So are you saying you fully trust that guest and > >>>>>>>>obviously the user installing rogue app? > >>>>>>>I don't think that app downloaded from Play Marget can access OP-TEE directly. > >>>>>>>OP-TEE can be used by Android itself as a key storage or to access to a SE, > >>>>>>>for example. But 3rd app that issues TEE calls... I don't think so. > >>>>>> > >>>>>>You didn't get my point here. That rogue app may be able to break into > >>>>>>kernel via an exploit or have enough privilege to break the guest. Who knows > >>>>>>what it will be able to do after... > >>>>>Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed > >>>>>to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide > >>>>>some safer environment for sensitive data and code. This environment has > >>>>>well-defined interfaces and is desgined to be as safe as possible. > >>>>> > >>>>>If rogue app breaks into kernel, then it can issue any SMC which it wants. > >>>>>But OP-TEE does not trust to NW. Hypervisor does not trust to guests. > >>>>>Mediator should be written in the same way. > >>>>> > >>>>>So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is > >>>>>known issue. If there is a security bug in OP-TEE, it probably can overcome > >>>>>whole system. But this is true for any system running OP-TEE. > >>>> > >>>>I agree that if you take over OP-TEE, you will take over any system. This is > >>>>not specific to hypervisor. > >>>Yes. But it just occured to me that mediator+OP-TEE *can* be more > >>>secure then just OP-TEE. You see, mediator should perform own security > >>>checks before forwarding call to OP-TEE. So if OP-TEE misses > >>>something, mediator can back it up. I wouldn't rely on this. It just > >>>interesting thought :-) > >>> > >>>>Baremetal OS taking down the platform will only harm itself. A guest OS > >>>>could harm the whole platform. > >>>Can't argument with that. I think that this feature (shared TEE) is > >>>not suitable for, say, VPSes. But it can work just fine on smartphones > >>>or on another embedded devices, where vendor defines whole system. > >> > >>I guess your use case is "vendor defines whole system". But I am struggling > >>understand how this would more suitable there. > >Excuse me... "There" - it is where exactly? > > "vendor defines whole system". > > > > >>That guest OS may be "controlled" by the user. So how is that safer? > >Can you please define what is "safe" and "unsafe" in this context? > > > >Lets take a look at whole picture. I can see the following attacks: > > > >1) DoS attack. One domain spends all OP-TEE resources, other domains > > can't work with it. As I said earlier, this is know limitation. > > > >2) Mediator crash. Sort of DoS, if mediator can't restart properly. > > > >3) OP-TEE crash. This crashes whole system. > > > >4) Virtualization breach. Attacker gains control over mediator -> > > control over all TEE-enabled guests. > > > >5) Virtualization breach. Attacker gains control over hypervisor -> > > control over all guests. > > > >6) Virtualization breach. Attacker gains control over OP-TEE -> > > control over whole system, including firmware. > > > >Now it would be great to give you likehood for every attack type. But, > >obvioulsy I have no such numbers. I can only speculate about this. > > > >Returning to your question... To what extent guest OS can be controlled > >by user? Can user execute arbitrary code at EL1 for example? Or it can > >install only apps prebuilt by system vendor? > > > >What bad things will happen if user will compromise the whole system? > > > >Which guests will also run on the same system? Which subset of them > >will access OP-TEE? > > > >If you can asnwer to this questions, I can tell you, if it is safe > >to use OP-TEE + virtualization on your system. > > I don't make any end product and I have no idea what kind of guests would be > run on top. I know. I just wanted to emphasis that one selects stack (OSes, hypervisor, TEE, other parts) based on requirements. There are no silver bullet. For one project you can consider safe to use OP-TEE in any guest, while another project would require strict security policies and OP-TEE access only from one privileged domain. > So if I had to answers to those questions, I would consider all the guests > potentially nasty and therefore making sure the attack surface is limited > and understood. > > You really have to ask yourself what kinds of guest you will run on that > platform and assess the risk. Yes, exactly. > If you tell me you are going to run safety critical in one VM and another > with Android. Then I would be looking at limiting the attack surface of the > Android guest. True. For example, on Android I can employ SELinux to make sure that only framework (or even one separate service) can use TEE. > If you tell me that the user will only be able to install pre-built apps by > system vendor. Then I will have some trouble to believe it is secure given > how complex is an operating system. Actually, I don't see there nothing OP-TEE (or just TEE)- specific. I can have exactly the same concerns about PV drivers frontends-backends, or generic XEN interfaces. > And I am not even mentioning that allowing the user to install pre-built > apps by system vendor likely means having network/bluetooth access. I am > sure you have seen recently vulnerability... Yes. Actually, any decent SoC has lots of IP blocks that can execute arbitrary code. No one knows what is inside theirs firmwares and what security vulnerabilities they has. You know this better than me. We can discuss possible attacks indefinitely. OP-TEE is just another component of the system, and it, at least, is open source and is written WRT to security considerations. > > > >For some "generic" system I can say that it is pretty "safe" (except > >that problem with OP-TEE resources). > > > >>> > >>>>What I am not sure yet, maybe because of my lack of knowledge around OP-TEE, > >>>>who is going to protect a TA to access all the NS memory? > >>>TAs is runing in S-EL0. It can't control MMU. Before every TA > >>>invocation, OP-TEE setups MMU in such way, so TA sees only shared > >>>memory arguments passed by client for this particular invocation. > >> > >>Can you give a bit more details here? Particularly what is the life of that > >>mapped region? Is it just for a command? If not, who is going to unmap it > >>and when? > >Yes, this map is created for every call. TA code and data are mapped always, > >obviously. > > Where does the TA code and data live? Is it in secure or non-secure memory? It is in secure memory. OP-TEE support paging, BTW. So it can encrypt memory pages and store them in non-secure memory, if secure one is limited. But no sensitive data leaves secure memory unencrypted. TA binaries can be stored in normal world, but OP-TEE checks signatures during TA load process. > >But parameters are mapped every call and only needed ones. > >Example: I have shared buffers A, B, C, D. > > > >1) I call OpenSession(TA_UUID, A, B). > > TA sees only buffers A, B (okay, actually it sees whole page, because > > buffer is mapped from userspace). > > > >2) I call InvokeCommand(Session, CMD_ID, B, C). > > TA sees only buffers B & C. > > > >3) I call InvokeCommand(Session, CMD_ID, A, D). > > TA sees only buffers A & D. > > > >Note, that such buffers are not mapped at OP-TEE address space at all. > >They will be mapped only to TA address space. > > To confirm, what you are saying is as soon as any call is returned by TA, > the region will be unmapped from the TA address space? Yes. Also, just to clarify: TA executes only by request from client. It can't have external events. So, TA address space is somewhat ephemeral entity. It exists only during time between TA entry and TA exit. At all other times, TA does have no address space, no thread context, anything. Just code and data somewhere in memory. > > > >[...] > >>>>>>>>>>To be clear, this series don't look controversial at least for OP-TEE. What > >>>>>>>>>>I am more concerned is about DomU supports. > >>>>>>>>>Your concern is that rogue DomU can compromise whole system, right? > >>>>>>>> > >>>>>>>>Yes. You seem to assume that DomU using TEE will always be trusted, I think > >>>>>>>>this is the wrong approach if the use is able to interact directly with > >>>>>>>>those guests. See above. > >>>>>>>No, I am not assuming that DomU that calls TEE should be trusted. Why do you > >>>>>>>think so? It should be able to use TEE services, but this does not mean that > >>>>>>>XEN should trust it. > >>>>>> > >>>>>>In a previous answer you said: "So, if you don't trust your guest - don't > >>>>>>let it". For me, this clearly means you consider that DomU using TEE are > >>>>>>trusted. > >>>>>> > >>>>>>So can you clarify by what you mean by trust then? > >>>>>Well... In real world "trust" isn't binary option. You don't want to > >>>>>allow all domains to access TEE. Breached TEE user domain doesn't > >>>>>automatically mean that your whole system is compromised. But this > >>>>>certainly increases attack surface. So it is safer to give TEE access > >>>>>only to those domains, which really require it. You can call them > >>>>>sligtly more trusted, then others. > >>>> > >>>>Do you have an example of guest you would slightly trust more? > >>>I have an example of guest I would trust less: if I'm running server, > >>>and I'm selling virtual machines on that server, I don't want to them > >>>to access TEE. > >> > >>Make sense. > >> > >>> > >>>I will trust slightly more to my own guest. > >> > >>I kind of agree if there are either no interaction with the user or the user > >>is not able to gain privilege permissions. > >Okay, if user can execute arbitrary code at EL1... Even then nothing bad > >will happen. They must be able to hack mediator/hypervisor/OP-TEE to realy > >gain priviegs in system. > > My worry here is you base the trust on OP-TEE and not only the hypervisor. > At the moment we had to trust the hardware to do the right thing and the > software is owned by Xen. How about firmware? E.g. ARM TF? > Now you are telling me, we have this TEE running in EL3 and have to trust > him to do the isolation between guests. Until the last 2 e-mails, it was not > clear for me how OP-TEE could ensure this isolation. Actually, OP-TEE is running at S-EL1 :-) Only ARM TF (or whatever firmware is used) has ultimate control over the system. If we are talking about modern ARMv8 platforms. > I would advise to explain a bit more in your cover letter of your next > version the design of OP-TEE. This would help people to see how this can > work with the hypervisor and also understanding the consequence... I see. I'll do this, certainly. I just didn't expected that someone will be interested in OP-TEE internals at such level. But, I think, cover leter for next OP-TEE will be done much later. Now, I'm busy with OP-TEE part, then there will be changes to support multi-domain boot and only then OP-TEE specific patches... BTW, if anyone is interested in current state of OP-TEE mediator, you can find it at [1]. I was able to pass OP-TEE tests from DomU in the last version. I use it for OP-TEE development, so it is not production-ready. Julien, I want to ask about VM monitor feature in XEN. monitor_smc() function and whole xen/arch/arm/monitor.c... Looks like it was introduced for some sort of debugging. Do you know any users of this? [1] https://github.com/lorc/xen/tree/optee WBR, -- Volodymyr Babchuk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator 2017-11-02 20:07 ` Volodymyr Babchuk @ 2017-11-07 16:03 ` Julien Grall 0 siblings, 0 replies; 44+ messages in thread From: Julien Grall @ 2017-11-07 16:03 UTC (permalink / raw) To: Volodymyr Babchuk Cc: Julien Grall, nd, Stefano Stabellini, jens.wiklander, xen-devel Hi Volodymyr, On 02/11/17 20:07, Volodymyr Babchuk wrote: > On Thu, Nov 02, 2017 at 05:49:12PM +0000, Julien Grall wrote: >> On 02/11/17 16:53, Volodymyr Babchuk wrote: >>> On Thu, Nov 02, 2017 at 01:17:26PM +0000, Julien Grall wrote: >>>> On 24/10/17 20:02, Volodymyr Babchuk wrote: >>> But parameters are mapped every call and only needed ones. >>> Example: I have shared buffers A, B, C, D. >>> >>> 1) I call OpenSession(TA_UUID, A, B). >>> TA sees only buffers A, B (okay, actually it sees whole page, because >>> buffer is mapped from userspace). >>> >>> 2) I call InvokeCommand(Session, CMD_ID, B, C). >>> TA sees only buffers B & C. >>> >>> 3) I call InvokeCommand(Session, CMD_ID, A, D). >>> TA sees only buffers A & D. >>> >>> Note, that such buffers are not mapped at OP-TEE address space at all. >>> They will be mapped only to TA address space. >> >> To confirm, what you are saying is as soon as any call is returned by TA, >> the region will be unmapped from the TA address space? > Yes. > Also, just to clarify: TA executes only by request from client. It > can't have external events. So, TA address space is somewhat ephemeral > entity. It exists only during time between TA entry and TA exit. At > all other times, TA does have no address space, no thread context, > anything. Just code and data somewhere in memory. That's quite a good news :). Thank you for the explanation. > >>> >>> [...] >>>>>>>>>>>> To be clear, this series don't look controversial at least for OP-TEE. What >>>>>>>>>>>> I am more concerned is about DomU supports. >>>>>>>>>>> Your concern is that rogue DomU can compromise whole system, right? >>>>>>>>>> >>>>>>>>>> Yes. You seem to assume that DomU using TEE will always be trusted, I think >>>>>>>>>> this is the wrong approach if the use is able to interact directly with >>>>>>>>>> those guests. See above. >>>>>>>>> No, I am not assuming that DomU that calls TEE should be trusted. Why do you >>>>>>>>> think so? It should be able to use TEE services, but this does not mean that >>>>>>>>> XEN should trust it. >>>>>>>> >>>>>>>> In a previous answer you said: "So, if you don't trust your guest - don't >>>>>>>> let it". For me, this clearly means you consider that DomU using TEE are >>>>>>>> trusted. >>>>>>>> >>>>>>>> So can you clarify by what you mean by trust then? >>>>>>> Well... In real world "trust" isn't binary option. You don't want to >>>>>>> allow all domains to access TEE. Breached TEE user domain doesn't >>>>>>> automatically mean that your whole system is compromised. But this >>>>>>> certainly increases attack surface. So it is safer to give TEE access >>>>>>> only to those domains, which really require it. You can call them >>>>>>> sligtly more trusted, then others. >>>>>> >>>>>> Do you have an example of guest you would slightly trust more? >>>>> I have an example of guest I would trust less: if I'm running server, >>>>> and I'm selling virtual machines on that server, I don't want to them >>>>> to access TEE. >>>> >>>> Make sense. >>>> >>>>> >>>>> I will trust slightly more to my own guest. >>>> >>>> I kind of agree if there are either no interaction with the user or the user >>>> is not able to gain privilege permissions. >>> Okay, if user can execute arbitrary code at EL1... Even then nothing bad >>> will happen. They must be able to hack mediator/hypervisor/OP-TEE to realy >>> gain priviegs in system. >> >> My worry here is you base the trust on OP-TEE and not only the hypervisor. >> At the moment we had to trust the hardware to do the right thing and the >> software is owned by Xen. > How about firmware? E.g. ARM TF? My point here was anything involved in virtualization is at the moment the hardware and Xen. The ARM TF/firmware cannot be accessed directly/indirectly by any guest. So there are no concern to me. > >> Now you are telling me, we have this TEE running in EL3 and have to trust >> him to do the isolation between guests. Until the last 2 e-mails, it was not >> clear for me how OP-TEE could ensure this isolation. > Actually, OP-TEE is running at S-EL1 :-) Only ARM TF (or whatever > firmware is used) has ultimate control over the system. If we are > talking about modern ARMv8 platforms. > >> I would advise to explain a bit more in your cover letter of your next >> version the design of OP-TEE. This would help people to see how this can >> work with the hypervisor and also understanding the consequence... > I see. I'll do this, certainly. I just didn't expected that someone will > be interested in OP-TEE internals at such level. I like to understand what I sign for :). > > But, I think, cover leter for next OP-TEE will be done much later. Now, > I'm busy with OP-TEE part, then there will be changes to support > multi-domain boot and only then OP-TEE specific patches... > > BTW, if anyone is interested in current state of OP-TEE mediator, you > can find it at [1]. I was able to pass OP-TEE tests from DomU in the > last version. I use it for OP-TEE development, so it is not > production-ready. > > Julien, I want to ask about VM monitor feature in XEN. monitor_smc() > function and whole xen/arch/arm/monitor.c... Looks like it was > introduced for some sort of debugging. Do you know any users of this It was originally introduced to allow an external application trapping SMC and executing an action. This is part of the VM introspection framework that could be used to watch the behavior of the guest (see [2]). You could imagine trying to detect malware from outside the VM. > [1] https://github.com/lorc/xen/tree/optee [2] https://wiki.xenproject.org/wiki/Virtual_Machine_Introspection -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2017-11-07 16:03 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-11 19:01 [RFC 0/4] TEE mediator framework + OP-TEE mediator Volodymyr Babchuk 2017-10-11 19:01 ` [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC Volodymyr Babchuk 2017-10-16 14:53 ` Julien Grall 2017-10-11 19:01 ` [RFC 2/4] arm: add generic TEE mediator framework Volodymyr Babchuk 2017-10-16 13:00 ` Julien Grall 2017-10-17 16:22 ` Volodymyr Babchuk 2017-10-17 16:39 ` Julien Grall 2017-10-17 17:22 ` Volodymyr Babchuk 2017-10-17 17:35 ` Julien Grall 2017-10-11 19:01 ` [RFC 3/4] arm: tee: add OP-TEE header files Volodymyr Babchuk 2017-10-16 14:04 ` Julien Grall 2017-10-17 16:24 ` Volodymyr Babchuk 2017-10-17 16:41 ` Julien Grall 2017-10-11 19:01 ` [RFC 4/4] arm: tee: add basic OP-TEE mediator Volodymyr Babchuk 2017-10-16 14:36 ` Julien Grall 2017-10-17 17:08 ` Volodymyr Babchuk 2017-10-17 17:30 ` Julien Grall 2017-10-17 18:57 ` Volodymyr Babchuk 2017-10-19 14:01 ` Julien Grall 2017-10-19 15:33 ` Volodymyr Babchuk 2017-10-19 16:12 ` Julien Grall 2017-10-19 16:37 ` Volodymyr Babchuk 2017-10-19 16:52 ` Julien Grall 2017-10-16 12:00 ` [RFC 0/4] TEE mediator framework + " Julien Grall 2017-10-17 15:59 ` Volodymyr Babchuk 2017-10-20 13:11 ` Julien Grall 2017-10-20 16:57 ` Tamas K Lengyel 2017-10-20 17:46 ` Volodymyr Babchuk 2017-10-20 17:37 ` Volodymyr Babchuk 2017-10-23 16:59 ` Julien Grall 2017-10-23 20:11 ` Volodymyr Babchuk 2017-10-23 21:26 ` Stefano Stabellini 2017-10-24 16:33 ` Volodymyr Babchuk 2017-10-24 21:33 ` Stefano Stabellini 2017-10-27 13:47 ` Julien Grall 2017-10-27 19:59 ` Stefano Stabellini 2017-10-27 20:06 ` Julien Grall 2017-10-24 17:33 ` Julien Grall 2017-10-24 19:02 ` Volodymyr Babchuk 2017-11-02 13:17 ` Julien Grall 2017-11-02 16:53 ` Volodymyr Babchuk 2017-11-02 17:49 ` Julien Grall 2017-11-02 20:07 ` Volodymyr Babchuk 2017-11-07 16:03 ` Julien Grall
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.