Memory protection on RTEMS?

Thu Sep 10 13:49:57 UTC 2015

On Thu, Sep 10, 2015 at 12:02 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> 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.
>
+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.sherrill at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


-- 
Hesham