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 <rijure...@mpi-sws.org> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
