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
>
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.
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
>
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
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
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
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
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"
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