Re: [Xen-devel] [PATCH v1 4/6] optee: add OP-TEE mediator

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

Please only CC relevant people to the patches. This could be done easily 
using the new script add_maintainers.pl.
On 22/08/18 15:11, Volodymyr Babchuk wrote:
> Add OP-TEE mediator, so guests can access OP-TEE services.
>
> OP-TEE mediator support address translation for DomUs.
> It tracks execution of STD calls, correctly handles memory-related RPC
> requests, tracks buffer allocated for RPCs.
>
> With this patch OP-TEE sucessfully passes own tests, while client is
> running in DomU.
>
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
> ---
>
>   Changes from "RFC":
>   - Removed special case for Dom0/HwDOM
>   - No more support for plain OP-TEE (only OP-TEE with virtualization
>     config enabled is supported)
>   - Multiple domains is now supported
>   - Pages that are shared between OP-TEE and domain are now pinned
>   - Renamed CONFIG_ARM_OPTEE to CONFIG_OPTEE
>   - Command buffers from domain are now shadowed by XEN
>   - Mediator now filters out unknown capabilities and requests
>   - call contexts, shared memory object now stored per-domain
>
>   xen/arch/arm/tee/Kconfig            |   4 +
>   xen/arch/arm/tee/Makefile           |   1 +
>   xen/arch/arm/tee/optee.c            | 972 ++++++++++++++++++++++++++++++++++++
This patch is far to big to get a proper review with understanding of 
the code. Can you split it in smaller ones with appropriate commit message?
From a quick look at it, I would like to understand how the memory 
allocated in Xen is bounded for a given guest? Same question for the time.
I am interested in a normal case but also in the case where someone 
malicious is using that API. How much damage can it do to the hypervisor?
I will give a proper look when it is split.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel