i.MX53QSB port + IOmem access

[Andy Wagner]

PT checks are probably adequate <those should not be modifiable from usr>
but any user-context that can map the pages gets access.
IO and the io configuration enforce resource assignment policy here
and granularity is adequately fine to segregate resources via .cfg file
entries.

Agreed that trapping slows down IO process but could make porting
more transparent. Tradeoff is the amount of work required to manage
within the BSP and have that correspond to IO <or wherever the
handler would be most suitable>. There is work in either case and
it is probably more easily achieved by having the bits cleared
at boot or init and minimizing changes required to linux.

TZ would be still more entertaining to support.

thanks,
   Andy



On Tue Aug 07, 2012 at 13:41:56 -0700, Andy Wagner wrote:
 > Clearing sp for opacr21 allows the access to complete without fault.
 > It would be very nice if the sp could remain enabled and have the
 > fault handler trap to supervisor so that hardware enforcement can
 > be leveraged as well as software resource allocation check.
 >
 > Since mprot and opacr assignments are SoC specific this
 > would have to be implemented as part of the BSP framework perhaps
 > over complicating the issue. Preference is to keep things simple
 > and probably leave in the underlying linux, where the drivers
 > are located <executing code localization>, without making fiasco
 > or l4 more aware of the hardware than necessary. Instruction
 > emulation could be a bit messy due to differing memory maps
 > between faulting and exception handling contexts.

Well, the hardware enforcement used is the page table which makes sure
that a client can only access those devices it is given access to. Which
benefit does a user/supervisor access check add here? Trapping any
access to io memory would also slow down access to devices, plus someone
would need to check if the access is valid, which would not be the
kernel.



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
   Lackorzynski         http://os.inf.tu-dresden.de/~adam/