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