[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 Tue, Feb 7, 2017 at 1:51 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
Hi Tamas,

On 07/02/2017 20:38, Tamas K Lengyel wrote:


On Tue, Feb 7, 2017 at 12:42 PM, Edgar E. Iglesias
<edgar.iglesias@xxxxxxxxx <mailto:edgar.iglesias@gmail.com>> wrote:

    From: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx
    <mailto:edgar.iglesias@xilinx.com>>

    Allow platform_hvc to handle guest SMC calls (as well as
    HVC calls) in a platform specific way.

    Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xxxxxxxxxx
    <mailto:edgar.iglesias@xilinx.com>>
    ---
     xen/arch/arm/traps.c | 5 +++++
     1 file changed, 5 insertions(+)

    diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
    index 33950d9..1bedc6e 100644
    --- a/xen/arch/arm/traps.c
    +++ b/xen/arch/arm/traps.c
    @@ -2623,6 +2623,11 @@ static void do_trap_smc(struct cpu_user_regs
    *regs, const union hsr hsr)
         if ( current->domain->arch.monitor.privileged_call_enabled )
             rc = monitor_smc();


I think you should check that rc is still 0 at this point as the vCPU
might already be paused and the event forwarded to a monitor subscriber.

SMC are used to access the secure firmware (e.g power management) and will be used by the guest to access the secure firmware. Today, the code is expecting all event to be trapped by the monitor app and software emulated. However, some SMCs may be needed to be forwarded to the secure firmware, how do you expect it to work together?

It is something I already brought up when SMC trap was added and it is probably time to figure out what to do because this will not be the first series bringing the problem. For instance if you want to do video decoding or even payment on Android you may need to access the secure firmware for cryptography. At the same time, you also want to be able to monitor your guest.


Hi Julien,
monitoring SMCs using the monitor system should be incompatible with Xen routing the SMCs elsewhere. Since the monitor system is disabled by default I think this should be fine for everyone and not get in the way of people accessing the firmware in other usecases or routing SMCs elsewhere as needed.

As for applications that want to use SMC monitoring but also access the firmware, it can be accomplished by the monitor application on behalf of the VM.  While this adds a detour, this detour is by design as it adds a layer between untrusted VMs and the TZ so that any potential exploit targeting the TZ would first have to go through the monitor application (see https://www.sec.in.tum.de/publications/publication/322 for more info on the idea).

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.