On Wed, Feb 8, 2017 at 9:58 AM, Julien Grall <julien.gr...@arm.com> wrote:
> 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.igles...@xilinx.com <mailto: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 >> <mailto:julien.gr...@arm.com>> 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. > It is not intended to work with just any TrustZone. In the proposed system the TZ is specifically designed to minimize the codebase that is running at that privilege level. We mostly envisioned critical integrity and security checks to be in the TZ while all "normal" TZ applications would be delegated to VMs - still protected from the untrusted guest, but a potential exploit would just land the attacker in another VM rather then the TZ. At the moment it is just an experimental setup, so I don't expect it to be a drop-in solution for off-the-shelf phones in the near future. > > >> 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 don't see an issue with the monitor application modifying register values on a trapped SMC. The issue I have is if the SMC is still forwarded to the firmware by Xen afterwards. In the usecase I described the firmware should under no situation be accessible from an untrusted guest directly. > > 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]). > Just modifying registers would not really accomplish filtering. We could introduce a vm_event response flag so the monitor application would be able to tell Xen whether it's OK to forward the SMC to the firmware or not. That is an option, even if I don't have a usecase for it. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
