On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall <julien.gr...@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.igles...@gmail.com <mailto:edgar.igles...@gmail.com>> wrote:
>>
>>     From: "Edgar E. Iglesias" <edgar.igles...@xilinx.com
>>     <mailto:edgar.igles...@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.igles...@xilinx.com
>>     <mailto:edgar.igles...@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@lists.xen.org
https://lists.xen.org/xen-devel

Reply via email to