Memory protection on RTEMS?

[Daniel Gutson]

El 9/9/2015 16:14, "Gedare Bloom" <gedare at rtems.org> escribió:
>
> On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> > Hello Martin,
> >
> > ----- Martin Galvan <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?

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
> > PGP     : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150909/1e77102e/attachment.html>