Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Thu, Feb 9, 2017 at 11:22 AM, Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
> On Thu, 9 Feb 2017, Edgar E. Iglesias wrote:
>> On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
>> > 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.
>>
>> Actually, MONITOR_OVERRIDE could allow dom0 full access to the Firmware
>> and only block guests. That would work better on the ZynqMP. I probably
>> overlooked this in your suggestion.
>
> Yes, the intention is to allow Dom0 full access to the firmware by
> default, even when memory introspection is enabled. The MONITOR_OVERRIDE
> tunable would change that, but would need to be explicitly enabled.

In principle I have nothing against a command line option, but I don't
really follow how that would help. The monitor system is disabled by
default for all domains, so there is no problem with dom0 booting or
any other domain needing to access the firmware. You specifically have
to enable the monitoring for domains. Why is it a problem to have it
be exclusive for just those domains where it is enabled?

Tamas

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