Hello all,
This is follow for patch series [1]. There was lots of discussions
for that series and I tried to address all of them in this new patchset.
Currently, I had a working solution for OP-TEE virtualization and it is being
upstreamed right now ([2]). So, I think it is a good time to introduce support
in XEN as well.
This series include generic TEE mediator framework and full-scale OP-TEE mediator
which is working with mentioned chages in OP-TEE. So, multiple domains can
work simultaneously with OP-TEE.
I added XSM support, so now it is possible to control which domains can work
with TEEs. Also I changed way how TEE discovery is done. Now it is very
generic and should support any platform.
[1] https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg01451.html
[2] https://github.com/OP-TEE/optee_os/pull/2370
Volodymyr Babchuk (6):
arm: add SMC wrapper that is compatible with SMCCC
arm: add generic TEE mediator framework
arm: tee: add OP-TEE header files
optee: add OP-TEE mediator
libxl: create DTS node for OP-TEE if it is enabled
xsm: add tee access policy support
MAINTAINERS | 5 +
tools/flask/policy/modules/dom0.te | 3 +
tools/flask/policy/modules/domU_with_tee.te | 23 +
tools/flask/policy/modules/modules.conf | 1 +
tools/flask/policy/modules/xen.if | 12 +
tools/libxl/libxl_arm.c | 29 +
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_parse.c | 1 +
xen/arch/arm/Kconfig | 10 +
xen/arch/arm/Makefile | 1 +
xen/arch/arm/arm32/Makefile | 1 +
xen/arch/arm/arm32/smc.S | 39 ++
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/asm-offsets.c | 4 +
xen/arch/arm/arm64/smc.S | 30 +
xen/arch/arm/domain.c | 7 +
xen/arch/arm/setup.c | 4 +
xen/arch/arm/shutdown.c | 2 +
xen/arch/arm/tee/Kconfig | 4 +
xen/arch/arm/tee/Makefile | 2 +
xen/arch/arm/tee/optee.c | 972 ++++++++++++++++++++++++++++
xen/arch/arm/tee/tee.c | 89 +++
xen/arch/arm/vsmc.c | 5 +
xen/arch/arm/xen.lds.S | 7 +
xen/include/asm-arm/processor.h | 11 +
xen/include/asm-arm/tee/optee_msg.h | 444 +++++++++++++
xen/include/asm-arm/tee/optee_smc.h | 507 +++++++++++++++
xen/include/asm-arm/tee/tee.h | 103 +++
xen/include/xsm/dummy.h | 10 +
xen/include/xsm/xsm.h | 13 +
xen/xsm/dummy.c | 4 +
xen/xsm/flask/hooks.c | 15 +
xen/xsm/flask/policy/access_vectors | 7 +
xen/xsm/flask/policy/security_classes | 1 +
35 files changed, 2369 insertions(+)
create mode 100644 tools/flask/policy/modules/domU_with_tee.te
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/tee.c
create mode 100644 xen/include/asm-arm/tee/optee_msg.h
create mode 100644 xen/include/asm-arm/tee/optee_smc.h
create mode 100644 xen/include/asm-arm/tee/tee.h
--
2.7.4
Dear All,
My name is Nguyen Duc Hoa, come from Vietnam.
I am working on Zynq Zybo-Z7 for porting optee to secure world.
I just had a trouble when Op-TEE OS is loading the kernel image(zImage).
Below image is my flow.
I refered from below topic and build up my system.
https://github.com/OP-TEE/optee_os/issues/1887
"U-Boot will load TEE and zImage, so need to verify the two images in
U-Boot. `kernel_entry` will run into the address passed to bootm. When
optee returns back, it will directly runs into the load address of zImage
and continue booting kernel. "
But on my side, in stage of booting kernel, I got an "kernel panic". (full
log is attached)
Following is how I did it:
1. Build OP-TEE with:
make PLATFORM=zynq7k CROSS_COMPILE="ccache arm-linux-gnueabihf-" ARCH=arm
CFG_TEE_CORE_LOG_LEVEL=4 CFG_DT_ADDR=0x02A00000 CFG_DT=y
CFG_TEE_TA_MALLOC_DEBUG=y CFG_TEE_CORE_MALLOC_DEBUG=y
CFG_TEE_CORE_USER_MEM_DEBUG=4 CFG_TEE_TA_LOG_LEVEL=4
CFG_NS_ENTRY_ADDR=0x03000000
arm-linux-gnueabihf-objcopy -O binary tee.elf tee.bin
2. Use mkimage to produce the uTee image. Make it looks like uImage so the
bootm command can boot it.
./mkimage -A arm -O linux -C none -a 0x3E000000 -e 0x3E000000 -d tee.bin
uTee
3. Make the linux kernel use xilinx_zynq_defconfig
Enable OpTee and EARLYCON
# OPTEE stuff
CONFIG_TEE=y
CONFIG_OPTEE=y
CONFIG_ARM_PSCI_FW=y
CONFIG_HAVE_ARM_SMCCC=y
CONFIG_SERIAL_EARLYCON=y
+ DTS file is attached
+ Make kernel by below command
make ARCH=arm xilinx_zynq_defconfig
CROSS_COMPILE=arm-linux-gnueabihf- make ARCH=arm
4. In u-boot kernel, load everything in place and use bootm to enter
OP-TEE
mmcinfo ; fatload mmc 0 0x03000000 zImage ; fatload mmc 0 0x02A00000
zImage-zynq-zybo-z7.dtb ; fatload mmc 0:1 0x3E000000 uTee; setenv
bootargs earlyprintk console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootwait
; bootm 0x3E000000 - 0x02A00000 ;
*** QUESTIONS ***
1. Is this flow correct?
2. I refer to this thread mail
https://lists.linaro.org/pipermail/tee-dev/2015-September/000176.html
and I saw that in my side, after back to non secure world, it seem to be
u-boot's environment variables was changed.
For purpose of booting kernel, I must keep the u-boot's context and OpTEE
OS switch to non-secure world this context will be restore, do I?
So anyone have better understanding about this flow, it will be helpful for
my further development.
Thank you very much in advance.
Hi, everyone,
I find that pager uses AES-GCM to protect data sections. I see that
the initialization vectors (IVs) used in AES-GCM for every page is
initialized to be zero. However, according to the NIST 800
specification [1]: IV should not repeat, otherwise AES-GCM may be
vulnerable to the forgery attacks [2]. So I suggest concatenating the
physical address of each page (DRAM address) and the IV, then the
concatenated IVs will be different for each page.
I also see that pager is removed from many devices, such as i.mx and
Hikey. Doesn't OP-TEE support pager any more?
Best Regards,
Shijun Zhao
1. Dworkin M. NIST special publication 800-38B[J]. NIST special
publication, 2005, 800(38B): 38B.
2. A. Joux, Authentication Failures in NIST version of GCM, Natl.
Inst. Stand. Technol. [Web page],
http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Se….
Hi,
I have tagged 3.2.0-rc1 yesterday, please help test it.
I will collect Tested-bys on https://github.com/OP-TEE/optee_os/pull/2404.
Of course, feel free to use the GitHub issues/pull request pages in case
something is wrong.
Thanks,
--
Jerome
On 14 June 2018 at 10:30, Jerome Forissier <jerome.forissier(a)linaro.org>
wrote:
> Hello OP-TEE contributors and maintainers,
>
> It is time to prepare for release 3.2.0. I will create the -rc1 tag next
> Wednesday (June 20), and hopefully the final release will follow one week
> later.
>
> So, if there are things you would like included in 3.2.0, please push them
> now. Please update your pending pull requests, help review patches, run
> some tests on master, etc. After -rc1 and until the release, we will take
> only bug fixes into master, as usual.
>
> I will let you know when the -rc1 tag is ready for testing.
>
> Thanks for your continued help and support!
> --
> Jerome
>
Hi
Can only help with resolving the following issue with building optee?
This is a bug I filed recently in the linaro bug database:
Simon Hughes<mailto:simon.hughes@arm.com> 2018-06-13 16:36:50 UTC
Changes committed to openembedded-core master within the last 24hrs have broken the mbed Linux build which uses meta-linaro:
===================================================================
02:48:15 ERROR: Logfile of failure stored in: /work/machine-imx7s-warp-mbl/mbl-manifest/build-mbl/tmp-mbl-glibc/work/cortexa7hf-neon-oe-linux-gnueabi/optee-client/2.6.0+gitAUTOINC+73b4e490a8-r0/temp/log.do_compile.12265
02:48:15 Log data follows:
02:48:15 | DEBUG: Executing shell function do_compile
02:48:15 | NOTE: make -j 24
02:48:15 | Building libteec.so
02:48:15 | CC src/tee_client_api.c
02:48:15 | CC src/teec_trace.c
02:48:15 | src/teec_trace.c: In function '_dprintf':
02:48:15 | src/teec_trace.c:110:24: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 246 [-Werror=format-truncation=]
02:48:15 | "%s [%d] %s:%s:%d: %s",
02:48:15 | ^~
02:48:15 | src/teec_trace.c:112:11:
02:48:15 | line, raw);
02:48:15 | ~~~
02:48:15 | src/teec_trace.c:109:3: note: 'snprintf' output 11 or more bytes (assuming 266) into a destination of size 256
02:48:15 | snprintf(prefixed, MAX_PRINT_SIZE,
02:48:15 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
02:48:15 | "%s [%d] %s:%s:%d: %s",
02:48:15 | ~~~~~~~~~~~~~~~~~~~~~~~
02:48:15 | trace_level_strings[level], thread_id, prefix, func,
02:48:15 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
02:48:15 | line, raw);
02:48:15 | ~~~~~~~~~~
02:48:15 | cc1: all warnings being treated as errors
02:48:15 | Makefile:52: recipe for target '/work/machine-imx7s-warp-mbl/mbl-manifest/build-mbl/tmp-mbl-glibc/work/cortexa7hf-neon-oe-linux-gnueabi/optee-client/2.6.0+gitAUTOINC+73b4e490a8-r0/git/libteec/../out/libteec/teec_trace.o' failed
02:48:15 | make[1]: *** [/work/machine-imx7s-warp-mbl/mbl-manifest/build-mbl/tmp-mbl-glibc/work/cortexa7hf-neon-oe-linux-gnueabi/optee-client/2.6.0+gitAUTOINC+73b4e490a8-r0/git/libteec/../out/libteec/teec_trace.o] Error 1
02:48:15 | make[1]: *** Waiting for unfinished jobs....
02:48:15 | Makefile:31: recipe for target 'build-libteec' failed
02:48:15 | make: *** [build-libteec] Error 2
02:48:15 | ERROR: oe_runmake failed
02:48:15 | WARNING: exit code 1 from a shell command.
02:48:15 | ERROR: Function failed: do_compile (log file is located at /work/machine-imx7s-warp-mbl/mbl-manifest/build-mbl/tmp-mbl-glibc/work/cortexa7hf-neon-oe-linux-gnueabi/optee-client/2.6.0+gitAUTOINC+73b4e490a8-r0/temp/log.do_compile.12265)
02:48:15 NOTE: recipe optee-client-2.6.0+gitAUTOINC+73b4e490a8-r0: task do_compile: Failed
02:48:15 NOTE: recipe alsa-state-0.2.0-r5: task do_install: Succeeded
02:48:15 ERROR: Task (/work/machine-imx7s-warp-mbl/mbl-manifest/build-mbl/conf/../../layers/meta-linaro/meta-optee/recipes-security/optee/optee-client.bb:do_compile) failed with exit code '1'
02:48:15 NOTE: recipe modutils-initscripts-1.0-r7: task do_install: Started
===================================================================
between
openembedded-core master commit bad: 8ab5b439ea82ac775494a0ce7a6f3615b61c94be
openembedded-core master commit good:23f15c63777020f5d43b070a1eb2bcf246c19ff8
Here is the diff between mbl-manifest pinned-manifest.xml's between <bad build nad >good build
simhug01@mbed-linux-test:/mnt/data/default_20180613_122141/mbl-manifest$ cat ../manifest_xml_changes.txt
20,21c20,21
< <project name="openembedded/meta-openembedded" path="layers/meta-openembedded" remote="github" revision="d9e257abbe16b9d30171493fa8f1d7e2d24cefe5" upstream="master"/>
< <project name="openembedded/openembedded-core" path="layers/openembedded-core" remote="github" revision="8ab5b439ea82ac775494a0ce7a6f3615b61c94be" upstream="master"/>
---
> <project name="openembedded/meta-openembedded" path="layers/meta-openembedded" remote="github" revision="bb57bac845f3cd1634862fa9868bc8e294ba74a9" upstream="master"/>
> <project name="openembedded/openembedded-core" path="layers/openembedded-core" remote="github" revision="23f15c63777020f5d43b070a1eb2bcf246c19ff8" upstream="master"/>
Other triage information:
triage:
◾This build succeeded: http://xxxxx/job/mbl-master/559/
◾This build failed: http://xxxxx//job/mbl-master/560/<http://xxxxx/job/mbl-master/560/>
◾The only projects that added changes between these to versions are openembedded-core and meta-openembedded (not meta-linaro containing meta-optee which holds the breaking optee-client.bb recipe).
◾Pinning oe-core in default.xml manifest to build 559 pin builds successfully (leaving meta-oe at head of master).
◾Pinning meta-oe in default manifest to build 559 pin doesn't build successfully (leaving oe-core at head of master).
◾Numerous oe-core changes have been added wrt gcc compiler recipes. Likely that a compiler option has been added to treat certain warnings as errors causing the latest break.
◾Should notify linaro project of the break and see if they fix it, or whether oe-core changes accommodate (less likely).
Approach Linaro staff member Ryan Harkin as a Linaro interface to bug logger.
Thanks
Simon
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
I'm learning the Trusted application that can be run in the TEE.
I was wondering whether there are some ways to check the .ta file's
instructions, just like using objdump or readelf on ELF.
I'm also interested how does the .ta be protected? What's the difference
between the .ta and normal executable?
Would it be possible to give me some information about that?
Thanks in advance!
Brs,
YL
Hello OP-TEE contributors and maintainers,
It is time to prepare for release 3.2.0. I will create the -rc1 tag next
Wednesday (June 20), and hopefully the final release will follow one week
later.
So, if there are things you would like included in 3.2.0, please push them
now. Please update your pending pull requests, help review patches, run
some tests on master, etc. After -rc1 and until the release, we will take
only bug fixes into master, as usual.
I will let you know when the -rc1 tag is ready for testing.
Thanks for your continued help and support!
--
Jerome