Memory protection on RTEMS?

[Joel Sherrill]

On 9/9/2015 5:27 PM, Daniel Gutson wrote:
>
> El 9/9/2015 16:14, "Gedare Bloom" <gedare at rtems.org <mailto:gedare at rtems.org>> escribió:
>  >
>  > On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
>  > <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>> wrote:
>  > > Hello Martin,
>  > >
>  > > ----- Martin Galvan <martin.galvan at tallertechnologies.com <mailto:martin.galvan at 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.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985