memory reference monitor in SW

[Rijurekha Sen]

Quoted from http://soda.swedish-ict.se/3865/1/Thesis%252020100226.pdf:

"One of the major shortcomings of TrustZone is that it does not enable interposition on all exception types – as described earlier, system calls, undefined instruction exceptions, and MMU (both data and prefetch) aborts cannot be configured to trap to Monitor mode. Of course, it could be possible to have privileged mode exception handlers in the Normal world that forward exceptions to the Secure world via a monitor call, but this may not be feasible, reasonable, or trustworthy, depending on the situation.” - Page 79

"TrustZone offers no built-in way to intercept all Normal world exception types, and therefore no way to interpose on all guest kernel entries and exits. However, there is a way around this issue. The problem can be remedied by paravirtualizing the guest kernel. This effort could be rather minimal, potentially involving only the insertion of a SMC instruction at the start of each exception handler in the guest OS, or in the exception vector table.” - Page 81

What kind of exception happens when NW accesses a secure physical address? Will that trap to monitor mode? I cannot para-virtualize the android kernel, to include SMC() around exceptions, as the threat model is an untrusted user/OS.

Thanks!
Riju 


On Nov 11, 2016, at 5:07 PM, Rijurekha Sen <rijurekha at ...71...> wrote:

> I have an imx53 sabre tablet. I am trying to implement a reference monitor in SW, to create a trace for memory accesses from android running in NW.
> 
> I do not need to monitor all memory accesses, but those corresponding to IPU and I2C. I am actually interested in the OV5642 camera module - and want to monitor in SW all memory read/writes corresponding to android camera activities running in NW. Going through the android device driver code, saw that IPU and I2C do the memory related operations and configurations for the camera. In http://www.mit.edu/afs.new/sipb.mit.edu/project/freebsd/head/sys/gnu/dts/arm/imx53.dtsi, which matches the IMX53 reference manual, the IPU and three I2C physical address ranges are mentioned.
> 
> If I want to create a reference monitor for these physical memory addresses, should I mark these as secure memory? According to https://community.arm.com/thread/4852#15483, to just read/write NW pages, SW doesn’t need extra hardware configuration like TZASC, M4IF, TZPC or CSU. This is possibly what https://www.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_TRUST/PubsPDF/mobisys16_restricted-spaces.pdf uses to check/modify android loaded in NW RAM. But my SW will need to know when NW is making a particular memory access, so the ability to passively read/write NW memory locations from SW isn’t useful.
> 
> How can I mark multiple blocks of physical address ranges (corresponding to memory mapped IO and not SRAM/DRAM) as secure? The M4IF seems to split the DDR external memory into two blocks. Should I use TZASC, as according to genode documentation - "Due to experimentation, we were able to deduct the following insights. The TZASC controller on the platform is used to secure physical address ranges that are addressable through the Static Memory Controller (SMC). In principal, it should be possible to secure another memory controller by a TZASC too, but on the platform, it is restricted to the SMC. These physical address regions correspond to the I/O resources of peripheral devices, some SRAM, and flash memory.” Or do I need to configure the CSU? What is the way to configure TZASC or CSU, to make particular physical address ranges secure?
> 
> When some physical memory is marked as secure, does NW access there cause a data abort? Does it automatically trap to monitor code, and SW can see what NW instruction caused it? I will need to record that access in SW, emulate   that instruction in SW and give back control to NW.  I understand that because IPU is needed for any display related activity (and accel/magnetometer/audio … all seem to be I2C devices), making those memory regions secure will cause android to fault even at booting. So I will possibly see the intended behavior, even without using the android camera.
> 
> Thanks in advance for any suggestions on how to proceed.
> 
> Thanks!
> Riju
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi_______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20161111/0fbe3f47/attachment.html>