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

["Edgar E. Iglesias" <edgar.iglesias@xilinx.com>]

On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall <julien.grall@arm.com> 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@gmail.com <mailto:edgar.iglesias@gmail.com>> wrote:
> >>
> >>     From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com
> >>     <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@xilinx.com
> >>     <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).

I considered this approach a bit but it has several problems IMO.
These may not be unsolvable or even problems for monitoring but
they do introduce complexity into the solution.

1. Some SMC calls may depend on the core they are issued from.
   If taking a detour to dom0, this becomes messy to guarantee.

2. Overall complexity increases very significantly and it becomes
   quite hard to follow/review how these calls get handled.
   In particular once you consider solving #1.

3. There are certain calls that perhaps not even dom0 should have
   direct access to. This means that Xen may need to filter some of
   them anyway.

Some examples may be:

SMC calls:
* To directly turn off or suspend cores
* To turn off DDR or RAMs that Xen is using
* To a solution specific Trusted OS pinned to a specific core
* For PSCI
* Etc

I would prefer if we could find a way for monitoring to play nicely
with Xen implementing the SMC mediators.
Perhaps we could allow calls that Xen consumes to be monitored/inspected
but not modified. Or there might be other ways.

Best regards,
Edgar

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