On 9/9/2015 5:27 PM, Daniel Gutson wrote:
El 9/9/2015 16:14, "Gedare Bloom" <ged...@rtems.org <mailto:ged...@rtems.org>> escribió: > > On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber > <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > Hello Martin, > > > > ----- Martin Galvan <martin.gal...@tallertechnologies.com <mailto:martin.gal...@tallertechnologies.com>> schrieb: > >> Hi there! We were looking at the RTEMS SMP support, and wondered what > >> would it take for the system to support some form of memory protection > >> (say, an MPU). Is it possible, and if so, how hard would it be? > > > > the question is, what is "some form of memory protection" for you? > > > +1. Requirements differ in this space. Note that we do not intend to > have supervisor-privilege, so memory protection may be more applicable > for safety features or debugging, rather than security. Security is > guaranteed only if you can ensure no code injection and you have a > trusted code base. > > > A process model for RTEMS makes no sense. For this you better use a micro kernel or Linux. We want to protect a real time task's memory from being written or generally accessed from another task. That smells like processes, but the truth is we just need memory iisolation/protection meaning that a task trying to access something marked as owned by another task is because there is a bug and an action shall be taken (e.g. restart the offending task). Is there already any kind of hardware support for this?
Saying "task's memory" needs to be more specific. There are a fair number of different types of data including code, global data and BSS, stack, per thread data, etc. I assume the project Sebastian mentioned ended up with similar issues for the one we implemented MMU-based stack protection for. Once you define the "per task memory object" you want to protect, you have to allocate it on the correct alignment boundary to use the MMU. On that project, all task stacks were a fixed multiple of the page size and the mapped address space protected that. Beyond the alignment issues, somehow you have to manage the sets of MMU data structures. Are there enough for the number of tasks and objects. But this is implementation. From a requirements view, let's drill down on what types of memory objects there are and what makes sense. + code + data/bss + read only data + per thread data + stacks + C program heap + RTEMS Workspace + ? As Sebastian mentioned if you make the task stack accessible by only a single stack, you have to be careful not to pass pointers to objects on the stack into paths where they will be used by another task. But in general terms, once we look at the various types of logical memory objects, we can decide what protection makes sense, alignment impacts, page table limitations, etc. --joel
Thanks, Daniel. > > > > The ARMv7-A and some PowerPC BSPs have write protection for code and read-only data. On some BSPs, read/write to the NULL pointer leads to an exception. This is quite handy during development, but offers no real benefit for a production system. > > > > For one customer we implemented a stack protection, a thread can only access its own stack, but this is quite non-standard. > > > >> > >> We also saw this: > >> > >> https://devel.rtems.org/wiki/Projects/MMU_Support > >> > >> What's the status of this project? > > > > I don't know. MMU support tends to be highly architecture specific, so the development of a general purpose API is quite difficult. > > > I am (as we speak) working on a proposal to look in this direction. > I'm happy to talk more or to consider how to align our efforts. > > >> > >> On the other hand, we noticed that LEON3 IP Cores usually implement an > >> MMU instead of just an MPU. Would it be feasible to support that? > > > > The GR740 has an IOMMU (chapter 17). > > > > http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf > > > > -- > > Sebastian Huber, embedded brains GmbH > > > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > > Phone : +49 89 189 47 41-16 > > Fax : +49 89 189 47 41-09 > > E-Mail : sebastian.huber at embedded-brains.de <http://embedded-brains.de> > > PGP : Public key available on request. > > > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
