[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls
On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote: > On Thu, 9 Feb 2017, Julien Grall wrote: > > On 08/02/2017 23:28, Tamas K Lengyel wrote: > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall <julien.grall@xxxxxxx> 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.iglesias@xxxxxxxxx <mailto:edgar.iglesias@xxxxxxxxx>> 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." > > To have a generic solution, we need a way to specify a set of HVC/SMC > calls that get monitored and a set that get handled in Xen (platform > specific or otherwise). I think it is OK not to do both, at least at the > beginning, but we might want to add that feature in the future. > > As much as I would like to see that, in respect to this series, I don't > think we should ask Edgar to introduce such a mechanism. However, we do > need to decide what Xen should do when platform_hvc is implemented and > monitor is also enabled. > > I think the default should be to only call platform_hvc, because there > are many valid monitoring use-cases which don't require those few > platform specific SMC/HVC calls to be forwarded to the monitor. > > However, if we did that, we would break Tamas' scenario. Thus, I suggest > we also introduce a simple compile time option or Xen command line > option to forward all platform_hvc calls to the monitor instead of > implementing them in Xen. Something like "MONITOR_OVERRIDE". In the > future, we can replace it with a more generic framework to dynamically > configure at runtime which SMC/HVC calls get forwarded. > > What do you think? This could work in some scenarios, but for example on the ZynqMP, dom0 needs access to Firmware as it boots, otherwise a lot of I/O will end up non-functional (with recent kernels). Anyway, I think it would give us a path forward. Future patches could either implement finer control or something else. Perhaps a hypercall to allow dom0 to turn off any platform_hvc handling for a given guest would help. If that mode is enabled, Xen is hands off on any platform specific HVC/SMC. It still leaves the problem open for other calls but I must say I find it strange to emulate the Xen Hypercalls in dom0 user-space. AFAIK, the monitor is not looking at HVC today. So it is allowing PSCI firmware calls through Xen's PSCI mediator/emulator. Some of these calls may sometimes hit firmware, so the point of isolating a guest completely from Firmware access is not valid today. Cheers, Edgar > > > 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. > > Each platform is different. It seems unlikely to me too, and it might > always remain a niche use-case, but it is still a valid scenario to > consider. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |