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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Tamas,

On 08/02/17 16:40, Tamas K Lengyel wrote:
> On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
> <edgar.iglesias@xxxxxxxxxx <mailto:edgar.iglesias@xxxxxxxxxx>> wrote:
>     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@xxxxxxx
>     <mailto:julien.grall@xxxxxxx>> wrote:
>     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
>
>
> Hi Edgar,
> certainly there are many cases where the system would become very
> complex when there is functionality like what you describe in the TZ
> that needs to be made accessible via SMC. The setup I described is
> experimental only, and the underlying assumption is that the TZ is
> working jointly with the monitor application (ie. both are aware of each
> other). So it is really not intended to work with just any firmware.
How do you expect TrustZone to work with the monitor application? If you 
think about modifying Trustzone, it seems a requirement difficult to 
achieve as some Trusted OS are proprietary or difficult to replace on a 
phone.
> So I think for the sake of reducing complexity, having the monitor
> system be exclusive when enabled should make everyone's life simpler.
> Having a passive monitoring mode as you suggest is certainly an option,
> although it should not be the only option, exclusive routing of SMCs
> through monitor applications should still be available to be configured
> by the user. Since I really don't know of any usecases where passive
> monitoring of SMCs is required, I don't think we should go that route.
I see the SMC trap similar to a register trap. The monitor app will look 
at the register value and potentially modify it. What would be the issue 
to do the same for SMC?
I think a such model would fit the requirement for everyone. The monitor 
app can filter if necessary, and Xen would handle the mediation between 
multiple guests. I would also recommend to read the thread about OP-TEE 
support in Xen (see [1]).
Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02220.html
--
Julien Grall

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