Hi Julien,
Julien Grall writes:
Hi Volodymyr,
On 6/11/19 7:46 PM, Volodymyr Babchuk wrote:
This enumeration controls TEE type for a domain. Currently there is two possible options: either 'none' or 'optee'.
'none' is the default value and it basically disables TEE support at all.
'optee' enables access to the OP-TEE running on a host machine. This requires special OP-TEE build with virtualization support enabled.
Signed-off-by: Volodymyr Babchuk volodymyr_babchuk@epam.com
All the patches to optee.c should be merged together. They were split to ease up review. But they depend heavily on each other.
Changes from v5:
- Replaced "native" with "optee" in the commit description.
- Updated and extended documentation based on Julien Grall's and Ian Jackson's suggestions.
Changes from v4:
- "native" option was replaced with "optee"
- "tee" property was moved from arch-specific section to the global one. Documentation moved inside "Devices" section.
Changes from v3:
- tee_enabled renamed to tee_type. Currently two types are supported as described in the commit message
- Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition
Changes from v2:
- Use arch.tee_enabled instead of separate domctl
docs/man/xl.cfg.5.pod.in | 21 +++++++++++++++++++++ tools/libxl/libxl.h | 5 +++++ tools/libxl/libxl_arm.c | 13 +++++++++++++ tools/libxl/libxl_types.idl | 6 ++++++ tools/xl/xl_parse.c | 9 +++++++++ 5 files changed, 54 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index c99d40307e..e65ab6111f 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -1544,6 +1544,27 @@ Set maximum height for pointer device. =back +=item B<tee="STRING">
+B<Arm only.> Set TEE type for the guest. TEE is a Trusted Execution +Environment -- separate secure OS found on some platforms. B<STRING> can be one of the:
+=over 4
+=item B<none>
+Disable TEE support at all. This is the default value.
How about "Don't allow the guest to use TEE if present on the platform. This is the default value.".
I'm perfectly fine with this.
+=item B<optee>
+Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE +is required for this. If this option is selected, guest will be able
OOI, what happen if OP-TEE does not support virtualization. Will Xen forbid to use it?
Yes, Xen will get an error from OP-TEE during domain construction. This will lead to domain creation failure.
+to access to the real OP-TEE OS running on the host. Guest creation
s/real// it is redundant with the rest of the sentence. However, it does not really answer to the question regarding isolation.
Your assumption is correct - OP-TEE provides isolation on its side.
+will fail if OP-TEE have no resources for a new guest. Number of supported +guests depends on OP-TEE configuration.
How about the following description (correct me if my understanding is wrong):
"Allow a guest to access the host OP-TEE OS. Xen will mediate the access to OP-TEE and the resource isolation will be provided directly by OP-TEE. OP-TEE itself may limit the number of guests that can concurrently use it. This requires a virtualization-aware OP-TEE for this to work.
This feature is a B<technology preview>."
That's much better than my version. Thank you.
How can a user know whether OP-TEE supports virtualization? Is it configurable at build?
Yes, there is a special configuration option CFG_VIRTUALIZATION. This is covered in OP-TEE documentation at [1]
[1] https://optee.readthedocs.io/architecture/virtualization.html