- Stratos-dev - op-lists.linaro.org

Re: [Stratos-dev] OPTEE with Xen Dom0 kernel

by AKASHI Takahiro

On Fri, Dec 04, 2020 at 09:47:10AM +0000, Ruchika Gupta via Stratos-dev wrote: > Hi Volodymyr, > > On Thu, 3 Dec 2020 at 17:49, Volodymyr Babchuk <Volodymyr_Babchuk(a)epam.com> > wrote: > > > > > Hi Ruchika, > > > > Ruchika Gupta writes: > > > > > Hi Masami, > > > > > > Have you compiled OP-TEE with the CFG_VIRTUALIZATION set ? > > > > > https://urldefense.com/v3/__https://optee.readthedocs.io/en/latest/architec… > > [optee[.]readthedocs[.]io] > > > > > > I have also been trying to bring OPTEE up on the QEMU aarch64 environment > > > with xen but not much success as yet. > > > > > > > Long time ago I used QEMU to develop virtualization support. So it is > > one of the supported platforms. Can you share what issues you encountered? > > > I still haven't reached the part where I enable OP-TEE. My issues are with > the initial XEN setup on QEMU with TF-A images in path. > I have a working setup with > uboot->Xen->Dom0 linux on QEMU. > > Next I tried adding BL components in the flow. Linux boots up but crashes. > BL1 -> Bl2 -> Bl31 -> uboot -> xen -> Dom0 I thought that you said that you had succeeded to follow this path. I always use this sequence for my testing (on qemu-arm64). -Takahiro Akashi > Not sure but this may be due to the additional parameters I pass in QEMU > (-machine virt,secure=on). > Crash log which I see > * 1.757127] megasas: 07.714.04.00-rc1* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *[ 1.768278] physmap-flash 0.flash: physmap platform flash device: [mem > 0x00000000-0x03ffffff][ 1.770386] Internal error: synchronous external > abort: 96000050 [#1] PREEMPT SMP[ 1.771596] Modules linked in:[ > 1.772554] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.9.0-g28676a5aba66 > #1[ 1.773690] Hardware name: linux,dummy-virt (DT)[ 1.774383] pstate: > 60000005 (nZCv daif -PAN -UAO BTYPE=--)[ 1.775135] pc : > cfi_send_gen_cmd+0xd8/0x160[ 1.775752] lr : cfi_send_gen_cmd+0x7c/0x160[ > 1.776261] sp : ffff80001003b960[ 1.776717] x29: ffff80001003b960 x28: > ffff00003ad55080 [ 1.777340] x27: ffffc585e8bc6b90 x26: 0000000000000000 > [ 1.778193] x25: ffff00003dab9d80 x24: ffff00003ad55080 [ 1.779082] > x23: 0000000000000000 x22: ffff00003d870000 [ 1.779979] x21: > 0000000000000000 x20: ffff00003ad55080 [ 1.780841] x19: 0000000000000000 > x18: 0000000000000010 [ 1.781720] x17: 0000000000000000 x16: > 0000000000000012 [ 1.782661] x15: ffff00003d870470 x14: 3030303030303078 > [ 1.783494] x13: 30206d656d5b203a x12: 6563697665642068 [ 1.784389] > x11: 0000000000000008 x10: 0101010101010101 [ 1.785277] x9 : > 6d73796870203a68 x8 : 7f7f7f7f7f7f7f7f [ 1.786072] x7 : 0000000000000004 > x6 : 0000000000000004 [ 1.786870] x5 : 0000000000000000 x4 : > ffff00003d870470 [ 1.787669] x3 : 0000000000000004 x2 : ffff800014000000 > [ 1.788555] x1 : ffff800014000000 x0 : 0000000000f000f0 [ 1.789636] > Call trace:[ 1.790331] cfi_send_gen_cmd+0xd8/0x160[ 1.791067] > cfi_qry_mode_on+0x40/0x288[ 1.791724] cfi_probe_chip+0x54/0x790[ > 1.792310] mtd_do_chip_probe+0xd8/0x448[ 1.792993] > cfi_probe+0x18/0x28[ 1.793642] do_map_probe+0x34/0xa8[ 1.794331] > physmap_flash_probe+0x6fc/0x798[ 1.795225] > platform_drv_probe+0x54/0xa8[ 1.795907] really_probe+0xe4/0x3b0[ > 1.796571] driver_probe_device+0x58/0xb8[ 1.797096] > device_driver_attach+0x74/0x80[ 1.797696] __driver_attach+0x58/0xe0[ > 1.798176] bus_for_each_dev+0x70/0xc0[ 1.798653] > driver_attach+0x24/0x30[ 1.799140] bus_add_driver+0x14c/0x1f0[ > 1.808408] driver_register+0x64/0x120[ 1.808926] > __platform_driver_register+0x48/0x58[ 1.809606] > physmap_init+0x1c/0x28[ 1.810069] do_one_initcall+0x54/0x1b4[ > 1.810534] kernel_init_freeable+0x1d0/0x238[ 1.811054] > kernel_init+0x14/0x118[ 1.811550] ret_from_fork+0x10/0x34[ > 1.812724] Code: 54000240 7100107f 54000421 8b020022 (b9000040) [ > 1.814277] ---[ end trace 36c61f67f73db7e7 ]---[ 1.816078] Kernel panic > - not syncing: Attempted to kill init! exitcode=0x0000000b[ 1.817284] > SMP: stopping secondary CPUs[ 1.818381] Kernel Offset: 0x4585d7800000 > from 0xffff800010000000[ 1.819234] PHYS_OFFSET: 0xffffe20480000000[ > 1.819986] CPU features: 0x0240022,2180608a[ 1.820569] Memory Limit: > none[ 1.821198] ---[ end Kernel panic - not syncing: Attempted to kill > init! exitcode=0x0000000b ]---soc_term: read fd EOF* > > MY QEMU commands : > > For bios as u-boot > qemu-system-aarch64 \ > -nographic \ > -serial tcp:localhost:54320 -serial tcp:localhost:54321 \ > -smp 4 \ > -s -S \ > -cpu cortex-a57 \ > -d unimp -semihosting-config enable,target=native \ > -m 4096 \ > -bios u-boot.bin \ > -machine virtualization=true -machine virt,gic-version=3 \ > -no-acpi -device loader,file=xen,force-raw=on,addr=0x49000000 -device > loader,file=Image.gz,addr=0x47000000 -device > loader,file=rootfs.cpio.gz,addr=0x42000000 -device > loader,file=virt-gicv3.dtb,addr=0x44000000 -netdev user,id=vmnic -device > virtio-net-device,netdev=vmnic > > For bios as b1.bin > aarch64-softmmu/qemu-system-aarch64 \ > -nographic \ > -serial tcp:localhost:54320 -serial tcp:localhost:54321 \ > -smp 4 \ > -s -S *-machine virt,secure=on\* > -cpu cortex-a57 \ > -d unimp -semihosting-config enable,target=native \ > -m 4096 \ > * -bios bl1.bin \* > -machine virtualization=true -machine virt,gic-version=3 \ > -no-acpi -netdev user,id=vmnic -device virtio-net-device,netdev=vmnic > > On the u-boot prompt , I manually modify the fdt passed to xen. > > Any pointers on what could be possibly going wrong will be very helpful. > > Regards, > Ruchika > > > Regards, > > > Ruchika > > > > > > On Wed, 2 Dec 2020 at 06:50, Stefano Stabellini via Stratos-dev < > > > stratos-dev(a)op-lists.linaro.org> wrote: > > > > > >> CCing Volodymyr who maintains optee support in Xen > > >> > > >> > > >> On Wed, 2 Dec 2020, Masami Hiramatsu via Stratos-dev wrote: > > >> > Hi Alex, > > >> > > > >> > Have you enabled the OP-TEE support on Xen on your matchartbin? > > >> > > > >> > When I ran Xen Dom0 with OP-TEE, I got below error. > > >> > > > >> > [ 6.482047] optee: probing for conduit method. > > >> > (XEN) d0v18 Unhandled SMC/HVC: 0xbf00ff01 > > >> > [ 6.482301] nvme nvme0: 1/0/0 default/read/poll queues > > >> > [ 6.490154] optee: api uid mismatch > > >> > [ 6.498962] optee: probe of firmware:optee failed with error -22 > > >> > > > >> > Would you know this issue? > > >> > > > >> > Thank you, > > >> > > > >> > -- > > >> > Masami Hiramatsu > > >> > -- > > >> > Stratos-dev mailing list > > >> > Stratos-dev(a)op-lists.linaro.org > > >> > > > https://urldefense.com/v3/__https://op-lists.linaro.org/mailman/listinfo/st… > > [op-lists[.]linaro[.]org] > > >> > > > >> -- > > >> Stratos-dev mailing list > > >> Stratos-dev(a)op-lists.linaro.org > > >> > > https://urldefense.com/v3/__https://op-lists.linaro.org/mailman/listinfo/st… > > [op-lists[.]linaro[.]org] > > >> > > > > > > -- > > Volodymyr Babchuk at EPAM > -- > Stratos-dev mailing list > Stratos-dev(a)op-lists.linaro.org > https://op-lists.linaro.org/mailman/listinfo/stratos-dev

4 years, 6 months

2
1
0 0

Re: [Stratos-dev] OPTEE with Xen Dom0 kernel

by Ruchika Gupta

Hi Masami, Have you compiled OP-TEE with the CFG_VIRTUALIZATION set ? https://optee.readthedocs.io/en/latest/architecture/virtualization.html I have also been trying to bring OPTEE up on the QEMU aarch64 environment with xen but not much success as yet. Regards, Ruchika On Wed, 2 Dec 2020 at 06:50, Stefano Stabellini via Stratos-dev < stratos-dev(a)op-lists.linaro.org> wrote: > CCing Volodymyr who maintains optee support in Xen > > > On Wed, 2 Dec 2020, Masami Hiramatsu via Stratos-dev wrote: > > Hi Alex, > > > > Have you enabled the OP-TEE support on Xen on your matchartbin? > > > > When I ran Xen Dom0 with OP-TEE, I got below error. > > > > [ 6.482047] optee: probing for conduit method. > > (XEN) d0v18 Unhandled SMC/HVC: 0xbf00ff01 > > [ 6.482301] nvme nvme0: 1/0/0 default/read/poll queues > > [ 6.490154] optee: api uid mismatch > > [ 6.498962] optee: probe of firmware:optee failed with error -22 > > > > Would you know this issue? > > > > Thank you, > > > > -- > > Masami Hiramatsu > > -- > > Stratos-dev mailing list > > Stratos-dev(a)op-lists.linaro.org > > https://op-lists.linaro.org/mailman/listinfo/stratos-dev > > > -- > Stratos-dev mailing list > Stratos-dev(a)op-lists.linaro.org > https://op-lists.linaro.org/mailman/listinfo/stratos-dev >

4 years, 6 months

3
3
0 0

Re: [Stratos-dev] OPTEE with Xen Dom0 kernel

by Stefano Stabellini

On Wed, 2 Dec 2020, Masami Hiramatsu via Stratos-dev wrote: > Hi Joakim, > > 2020年12月2日(水) 17:10 Joakim Bech <joakim.bech(a)linaro.org>: > > > > On Wed, Dec 02, 2020 at 07:54:48AM +0000, Alex Bennée via Stratos-dev wrote: > > > > > > Masami Hiramatsu <masami.hiramatsu(a)linaro.org> writes: > > > > > > > Hi Alex, > > > > > > > > Have you enabled the OP-TEE support on Xen on your matchartbin? > > > > > > No I haven't... I'm not even sure how you would do so. > > > > > > > > > > > When I ran Xen Dom0 with OP-TEE, I got below error. > > > > > > > > [ 6.482047] optee: probing for conduit method. > > > > (XEN) d0v18 Unhandled SMC/HVC: 0xbf00ff01 > > > > [ 6.482301] nvme nvme0: 1/0/0 default/read/poll queues > > > > [ 6.490154] optee: api uid mismatch > > > > [ 6.498962] optee: probe of firmware:optee failed with error -22 > > > > > > > > Would you know this issue? > > > > > > No - perhaps some of the security folk have some insight? > > > > > When the kernel first run it either does a SMC or a HVC to see whether > > OP-TEE is running and runs with the expected version. I believe that is > > what is failing here. Which one depends on what you have it configured > > to be in DT. Since this is Xen it must be configured to use HVC. So as > > Ruchika mentioned in another reply, I'd guess that OP-TEE (TEE core on > > secure side hasn't been built with Virtualization enabled). It's a long > > time since I tried this personally, but the information for how to run > > it can be found here: > > https://optee.readthedocs.io/en/latest/architecture/virtualization.html > > Thank you for the information. > Yes, currently I configured OP-TEE to use SMC on my machine. > OK, I'll try to follow the above instruction. I haven't worked with optee so I don't know how to help you on this specific issue. However, I just want to point out that since Xen can trap HVM and SMC just as easily, there is no need to switch from SMC to HVC for OPTEE. It should work fine (or not fine) regardless, and I think EPAM mostly tested with SMC as transport. In short, the issue is most probably something else.

4 years, 6 months

3
2
0 0

Re: [Stratos-dev] OPTEE with Xen Dom0 kernel

by Stefano Stabellini

CCing Volodymyr who maintains optee support in Xen On Wed, 2 Dec 2020, Masami Hiramatsu via Stratos-dev wrote: > Hi Alex, > > Have you enabled the OP-TEE support on Xen on your matchartbin? > > When I ran Xen Dom0 with OP-TEE, I got below error. > > [ 6.482047] optee: probing for conduit method. > (XEN) d0v18 Unhandled SMC/HVC: 0xbf00ff01 > [ 6.482301] nvme nvme0: 1/0/0 default/read/poll queues > [ 6.490154] optee: api uid mismatch > [ 6.498962] optee: probe of firmware:optee failed with error -22 > > Would you know this issue? > > Thank you, > > -- > Masami Hiramatsu > -- > Stratos-dev mailing list > Stratos-dev(a)op-lists.linaro.org > https://op-lists.linaro.org/mailman/listinfo/stratos-dev >

4 years, 6 months

2
1
0 0

Re: [Stratos-dev] OPTEE with Xen Dom0 kernel

by Joakim Bech

On Wed, Dec 02, 2020 at 07:54:48AM +0000, Alex Bennée via Stratos-dev wrote: > > Masami Hiramatsu <masami.hiramatsu(a)linaro.org> writes: > > > Hi Alex, > > > > Have you enabled the OP-TEE support on Xen on your matchartbin? > > No I haven't... I'm not even sure how you would do so. > > > > > When I ran Xen Dom0 with OP-TEE, I got below error. > > > > [ 6.482047] optee: probing for conduit method. > > (XEN) d0v18 Unhandled SMC/HVC: 0xbf00ff01 > > [ 6.482301] nvme nvme0: 1/0/0 default/read/poll queues > > [ 6.490154] optee: api uid mismatch > > [ 6.498962] optee: probe of firmware:optee failed with error -22 > > > > Would you know this issue? > > No - perhaps some of the security folk have some insight? > When the kernel first run it either does a SMC or a HVC to see whether OP-TEE is running and runs with the expected version. I believe that is what is failing here. Which one depends on what you have it configured to be in DT. Since this is Xen it must be configured to use HVC. So as Ruchika mentioned in another reply, I'd guess that OP-TEE (TEE core on secure side hasn't been built with Virtualization enabled). It's a long time since I tried this personally, but the information for how to run it can be found here: https://optee.readthedocs.io/en/latest/architecture/virtualization.html -- Regards, Joakim

4 years, 6 months

2
1
0 0

OPTEE with Xen Dom0 kernel

by Masami Hiramatsu

Hi Alex, Have you enabled the OP-TEE support on Xen on your matchartbin? When I ran Xen Dom0 with OP-TEE, I got below error. [ 6.482047] optee: probing for conduit method. (XEN) d0v18 Unhandled SMC/HVC: 0xbf00ff01 [ 6.482301] nvme nvme0: 1/0/0 default/read/poll queues [ 6.490154] optee: api uid mismatch [ 6.498962] optee: probe of firmware:optee failed with error -22 Would you know this issue? Thank you, -- Masami Hiramatsu

4 years, 6 months

2
1
0 0

Stratos Project deliverables for STR-11

by Nataliya Korovkina

Hello, I'm going to look into the STR-11 task, specifically into Zephyr Dom0 on Cortex-A. Will be glad to synchronize with other people who watch the task as well. Thanks, Nataliya

4 years, 6 months

1
0
0 0

Fwd: Last UEFI Forum Webinar of 2020: Virtual Firmware for Intel Trust Domain Extensions

by François Ozog

Interesting to attend this one I think ---------- Forwarded message --------- From: UEFI Administration <admin(a)uefi.org> Date: Wed, 18 Nov 2020 at 23:59 Subject: Last UEFI Forum Webinar of 2020: Virtual Firmware for Intel Trust Domain Extensions To: <contributor(a)uefi.org> Cc: UEFI Administration <admin(a)uefi.org> *UEFI 2020 Virtual Plugfest Webinar: **Virtual Firmware for Intel Trust Domain Extensions* <https://www.brighttalk.com/webcast/18206/453600> *Tuesday, December 15, 2020* * Registration Now Open* Hello UEFI Forum Members, We would like to invite you to register for the upcoming *Virtual Firmware for Intel Trust Domain Extensions webinar* <https://www.brighttalk.com/webcast/18206/453600> apart of the UEFI 2020 Virtual Plugfest <https://uefi.org/node/4051>. This is your last chance to attend a UEFI Forum hosted webinar in 2020. The webinar, presented by Jiewen Yao of Intel, will introduce Intel Trust Domain Extensions Virtual Firmware architecture and cover how it records runtime measurements, manages private memory and more. The webinar will include a live, interactive Q&A discussion on WebEx with the presenter immediately following the presentation. Attendees will have the chance to ask questions and participate in a lively discussion. Register for the free, public webinar: *Virtual Firmware for Intel Trust Domain Extensions* <https://www.brighttalk.com/webcast/18206/453600> *Tuesday, December 15, 2020 * *Webinar Airing from 8:00 am – 9:00 am PT* *Interactive Q&A from 9:00 am – 9:30 am PT* Intel® Trust Domain Extensions (Intel® TDX) introduce architectural elements to help deploy hardware-isolated, virtual machines (VMs) called trust domains (TDs). Intel TDX is designed to isolate VMs from the virtual-machine manager (VMM)/hypervisor and any other non-TD software on the platform to protect TDs from a broad range of software. This presentation introduces the architecture for TDX Virtual Firmware (TDVF), and the firmware reference implementation available in open source. The talk covers how TDVF runs from the TD reset vector, records runtime measurements, manages private memory, interacts with the Intel TDX module in Secure Arbitration Mode (SEAM), and loads the operating system (OS). *Register for the webinar: *https://www.brighttalk.com/webcast/18206/453600 *Live WebEx Q&A information: * - https://nereus-587.my.webex.com/nereus-587.my/j.php?MTID=m4c27dc95e19f0c58f… - Meeting number: 126 544 0541 - Password: q2TPMRqMw36 (72876776 from phones and video systems) If you have any questions, please contact the UEFI Forum public relations team at press(a)uefi.org. Best Regards, The UEFI Forum PR Team -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 6 months

1
0
0 0

Linaro Stratos December 2nd 2020 Agenda

by Mike Holmes

Hi All The December 2nd agenda has an interesting item relating to OP-TEE and Virtualization; a slide deck has now been attached for this item. https://collaborate.linaro.org/display/STR/Stratos+Home Mike -- Mike Holmes | Director, Foundation Technologies, Linaro Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org> "Work should be fun and collaborative, the rest follows"

4 years, 6 months

1
0
0 0

[RFC PATCH 00/15] Xen guest-loader and arm64 build fixes/enhancements

by Alex Bennée

Hi, There are two parts to this series, broadly related because they are all to do with Xen. The first half is a re-spin of the guest-loader patches from a few weeks ago. The only changes are to move the generic-loader documentation into the manual and then add some words about the guest-loader. The second half of the series is an attempt to fix and then clean up the handling of Xen enabled builds. Recent changes to the build system broke the ability to build qemu-system-i386 on arm64 hosts with Xen support enabled. The actual fix for that: meson.build: fix building of Xen support for aarch64 should probably be rolled into the current release as it fixes a regression. The rest can wait until the tree re-opens. The patches broadly try to: - clean-up detection and reporting - be more explicit about linking stubs for accel - add an explicit CONFIG_XEN_HVM for x86 and finally allow you to build a qemu-system-aarch64 with Xen support. This is my first major foray into tweaking meson builds and it seems to occasionally come unstuck and requires a distclean and re-configure to un-wedge itself. The following need review: - meson.build: build a Xen aware qemu-aarch64-system - xen: only build HVM support under CONFIG_XEN_HVM - accel/stubs: drop unused cpu.h include - stubs/xen-hw-stub: drop xenstore_store_pv_console_info stub - include/hw/xen.h: drop superfluous struct - meson.build: clean-up summary reporting of XEN and it's features - meson.build: introduce CONFIG_XEN_HVM flag - meson.build: fix building of Xen support for aarch64 - accel/meson: you only need accelerator stubs for softmmu builds - docs: add some documentation for the guest-loader - docs: move generic-loader documentation into the main manual Alex Bennée (15): hw/board: promote fdt from ARM VirtMachineState to MachineState hw/riscv: migrate fdt field to generic MachineState device_tree: add qemu_fdt_setprop_string_array helper hw/core: implement a guest-loader to support static hypervisor guests docs: move generic-loader documentation into the main manual docs: add some documentation for the guest-loader accel/meson: you only need accelerator stubs for softmmu builds meson.build: fix building of Xen support for aarch64 meson.build: introduce CONFIG_XEN_HVM flag meson.build: clean-up summary reporting of XEN and it's features include/hw/xen.h: drop superfluous struct stubs/xen-hw-stub: drop xenstore_store_pv_console_info stub accel/stubs: drop unused cpu.h include xen: only build HVM support under CONFIG_XEN_HVM meson.build: build a Xen aware qemu-aarch64-system docs/generic-loader.txt | 92 ---------- docs/system/generic-loader.rst | 117 ++++++++++++ docs/system/guest-loader.rst | 54 ++++++ docs/system/index.rst | 2 + meson.build | 24 ++- hw/core/guest-loader.h | 34 ++++ include/hw/arm/virt.h | 1 - include/hw/boards.h | 1 + include/hw/riscv/virt.h | 1 - include/hw/xen/xen.h | 2 +- include/sysemu/device_tree.h | 17 ++ include/sysemu/xen-mapcache.h | 2 +- include/sysemu/xen.h | 9 +- accel/stubs/hax-stub.c | 1 - accel/stubs/xen-all-stub.c | 11 ++ accel/stubs/xen-stub.c | 2 - hw/arm/virt.c | 322 +++++++++++++++++---------------- hw/core/guest-loader.c | 140 ++++++++++++++ hw/riscv/virt.c | 20 +- softmmu/device_tree.c | 26 +++ stubs/xen-hw-stub.c | 4 - accel/Kconfig | 3 + accel/meson.build | 4 +- accel/stubs/meson.build | 13 +- hw/core/meson.build | 2 + hw/i386/xen/meson.build | 2 +- 26 files changed, 627 insertions(+), 279 deletions(-) delete mode 100644 docs/generic-loader.txt create mode 100644 docs/system/generic-loader.rst create mode 100644 docs/system/guest-loader.rst create mode 100644 hw/core/guest-loader.h create mode 100644 accel/stubs/xen-all-stub.c create mode 100644 hw/core/guest-loader.c -- 2.20.1

4 years, 6 months

6
33
0 0

2025

2024

2023

2022

2021

2020

Stratos-dev