On Thu, Sep 10, 2015 at 12:02 AM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > 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. > +1 Another issue is when I was working on this project, there were some trade-offs between implementing one or two level page tables. For example, we ended up implementing 1MiB sections on ARM to avoid the overhead of two-level translation (and to accommodate as much entries as could be within the TLB). This was a problem specially in boards with small memories, because clearly, 1MiB is quite big.
> 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 -- Hesham _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
