Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Hello,

Thank you all for the discussion. I want to summarize it a bit.

Looks like there are no objections about my initial list of
requirements. There was born another requirement in the discussion.
Thanks to Stefano for formulation it:

10. Domains on which the monitor privileged call feature is enabled
  (which is by default disabled for all domains) should not be able to
  issue firmware calls via SMCs/HVCs so that such calls reach the
  firmware directly. Xen should not bounce such calls to the firmware on
  behalf of the domain. Xen should not alter the state of the domain
  automatically (ie. incrementing PC). These calls should be exclusively
  transfered to the monitor subscriber for further processing.
  Hypercalls, virtual PSCI calls, virtual CPU services calls and virtual
  ARM architecture service calls remain unaffected.

Tamas, you have agreed with this, right?

So, looks like the HVC/SMC calls should be handled in the next way:

1.  Virtualized calls (like vPSCI) will be handled by hypervisor
2a. If a VM Monitor is installed for a domain, remaining calls will be
forwarded to the VM Monitor
2b. In another case, call will be forwarded to some other handler. In
absence of handler, SMCs from dom0 will be forwarded to firmware. All
other calls (HVCs or SMCs from domU) will cause Undefined Instruction
(Xilinx usecase).

Case 2b is to be discussed further. I like idea of EL0 handler, but as
I said on community call, I'm still working on the prototype.

Have I missed something?

On 11 February 2017 at 02:14, Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx> wrote:
> Hello,
>
> This e-mail is sort of follow-up to the two threads: [1] (my thread
> about TEE interaction) and [2] (Edgar's thread regarding handling SMC
> calls in platform_hvc). I want to discuss more broad topic there.
>
> Obviously, there are growing number of SMC users and current state of
> SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
> secure way, Xilinx wants to forward some calls directly to Secure
> Monitor, while allowing to handle other in userspace, etc.
>
> My proposition is to gather all requirements to SMC (and HVC) handling
> in one place (e.g. in this mail thread). After we' will have clear
> picture of what we want, we will be able to develop some solution,
> that will satisfy us all. At least, I hope so :)
>
> Also I want to remind, that there are ARM document called "SMC Calling
> Convention" [3]. According to it, any aarch64 hypervisor "must
> implement the Standard Secure and Hypervisor Service calls". At this
> moment XEN does not conform to this.
>
> So, lets get started with the requirements:
> 0. There are no much difference between SMC and HVC handling (at least
> according to SMCCC).
> 1. Hypervisor should at least provide own UUID and version while
> called by SMC/HVC
> 2. Hypervisor should forward some calls from dom0 directly to Secure
> Monitor (Xilinx use case)
> 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
> architecture service calls, etc.
> 4. Hypervisor should handle TEE calls in a secure way (e.g. no
> untrusted handlers in Dom0 userspace).
> 5. Hypervisor should support multiple TEEs (at least at compilation time).
> 6. Hypervisor should do this as fast as possible (DRM playback use case).
> 7. All domains (including dom0) should be handled in the same way.
> 8. Not all domains will have right to issue certain SMCs.
> 9. Hypervisor will issue own SMCs in some cases.
>
> This is high-level requirements. Feel free to expand this list.
>
> Current SMC handling code does not even handle PSCI calls. Only HVC
> trap handler have branch to handle PSCI calls. SMCs are forwarded to
> VM monitor subsystem. There are even no advance_pc() call, so monitor
> needs to advance PC by itself. Also, dom0 can't have monitor, so there
> are no way to handle SMCs that originate from dom0. So, basically,
> current code does not meet any requirements from above list. This
> means that we can start from scratch and develop any solution.
>
> But at this moment I only want to gather requirements. So feel free to
> point at what I have missed.
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02220.html
> [2] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00635.html
> [3] 
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
> --
> WBR Volodymyr Babchuk aka lorc [+380976646013]
> mailto: vlad.babchuk@xxxxxxxxx



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@xxxxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel