On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias <edgar.igles...@xilinx.com > 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.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). > > 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. 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. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
