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 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.

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.

Tamas

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