Julien, You are absolutely right there. I want to add some more concerns about current state of SMC handling in Xen. After that discussion about OP-TEE I created small PoC that employs MiniOS to handle SMCs using monitor mode. Also I did some benchmarking and found that SMC handling in MiniOS is ten times slower, than handling in XEN. But, still, it is pretty fast and I don't think this will be a problem. Anyways, I want to try another approach and handle SMCs in EL0 XEN mode. Real problem is that dom0 can't have monitor. This is pretty obvious if you think about it. But this completely ruins OP-TEE use case. As you remember, idea was to handle all SMCs in one place before they would reach OP-TEE. Sadly, with current design, you can't handle SMCs from dom0.
So, as you can see, there are many requirements for proper SMC handling in hypervisor. Current state is unsatisfactory, there are different approaches were proposed by me, by Edgar, but looks like they can't satisfy us all. Probably, we need completely different approach. Maybe, Xen EL0 apps can be a good way to offload tasks such as SMC handling, device emulation, hardware drivers (like cpu freq or thermal management), etc. Or some framework, where you can register handlers for specific op types,etc, etc. Anyways, I feel that we need to gather all requirements to SMC handling from all interested sides and then we need to develop some approach, that will satisfy all of us. I'm going to start new thread on this topic tomorrow, if you don't mind. On 9 February 2017 at 02:08, Julien Grall <julien.gr...@arm.com> wrote: > > > On 08/02/2017 23:28, Tamas K Lengyel wrote: >> >> On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall <julien.gr...@arm.com> wrote: >>> >>> Hi Tamas, >>> >>> Can you please try to configure your e-mail client to use '>' rather than >>> ' >>> '? It makes quite hard to read the e-mail. >> >> >> Hm, not sure why it switched but should be fine now. >> >>> On 08/02/2017 20:15, Tamas K Lengyel wrote: >>>> >>>> >>>> >>>> >>>> On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias >>>> <edgar.igles...@gmail.com <mailto:edgar.igles...@gmail.com>> wrote: >>>> On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote: >>> >>> >>> >>>> If platform_hvc() consumes an SMC, it's considered part of the Xen >>>> API. >>>> Visible but not filterable by a monitor. >>>> >>>> >>>> Platforms can then dictate which SMC calls are better handled within >>>> Xen and >>>> which ones can be exposed to dom0 user-space. >>>> >>>> In addition, there could be a hypercall to disable platform specific >>>> handling >>>> in Xen alltogether for a given guest. Then everything goes to dom0 >>>> user-space. >>>> >>>> It's a little messy... >>>> >>>> >>>> >>>> That is messy and I would not want any SMCs reaching the firmware when >>>> the monitor application is in use. The monitor interface is disabled by >>>> default and there aren't any known usecases where the SMC has to reach >>>> both the firmware and the monitor application as well. So I think it is >>>> safe to just make the two things mutually exclusive. >>> >>> >>> >>> If you look at the SMC Calling Convention [1] both HVC and SMC are >>> considered a conduit for service call to the secure firmware or >>> hypervisor. >>> It would be up to the hypervisor deciding what to do. >>> >>> Lets imagine the guest is deciding to use HVC to access the secure >>> firmware >>> (AFAIU this patch series is adding that), are you going to monitor all >>> the >>> HVCs (including hypercall)? >> >> >> There are some fundamental differences between HVC and SMC calls >> though. An HVC can only land in the hypervisor, so as a hypercall, I >> would expect it to be something I can deny via XSM. That is a >> sufficient option for now to block the path to the firmware. If we end >> up needing to support an application that uses that hypercall for >> something critical, then yes, it would also need to be hooked into the >> monitor system. At the moment this is not necessary. > > > My point is not about what is necessary at the moment. But what is right > things to do. If you look at the spec, HVC are not only for hypercall, but > any other kind of services. Why would you deny something that is valid from > the specification (see 5.2.1)? > > "The SMC calling convention, however, does not specify which instruction > (either SMC or HVC) to use to invoke a > particular service." > >> >> So if we are landing in do_trap_smc from an HVC call, I think it would >> be better to introduce a separate function for it rather then just >> bunching the two together here. >> >>> >>> Similarly, non-modified baremetal app could use SMC to power on/off the >>> vCPU >>> (see PSCI spec). Will you emulate that in the monitor app? >> >> >> Yes, the underlying setup requires that everything that is expected >> from the firmware to be performed either by the monitor app, or have >> the monitor app further delegate it somewhere that can perform the >> task. That can be either the firmware itself (if its safe), or an >> isolated VM if it is possible to perform the task there. I wouldn't >> call this emulation necessarily btw. > > > You haven't understood my point. Xen is currently emulating PSCI call for > the guest to allow powering up and down the CPUs and other stuff. If you > decide to trap all the SMCs, you would have to handle them. > > And yes it is emulation as you don't seem to be willing passing those SMC to > the firmware or even back to Xen. If we expect a VM to emulate a trusted > firmware, then you have a security problem. Some hardware may be only > accessible through the secure world and I doubt some trusted app vendor will > be willing to move cryptography stuff in non secure world. I would highly > recommend to skim through the OP-TEE thread, it will provide you some > insights of the constraints. > > Cheers, > > -- > Julien Grall -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
