<p dir="ltr"><br>
El 9/9/2015 16:14, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> escribió:<br>
><br>
> On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> > Hello Martin,<br>
> ><br>
> > ----- Martin Galvan <<a href="mailto:martin.galvan@tallertechnologies.com">martin.galvan@tallertechnologies.com</a>> schrieb:<br>
> >> Hi there! We were looking at the RTEMS SMP support, and wondered what<br>
> >> would it take for the system to support some form of memory protection<br>
> >> (say, an MPU). Is it possible, and if so, how hard would it be?<br>
> ><br>
> > the question is, what is "some form of memory protection" for you?<br>
> ><br>
> +1. Requirements differ in this space. Note that we do not intend to<br>
> have supervisor-privilege, so memory protection may be more applicable<br>
> for safety features or debugging, rather than security. Security is<br>
> guaranteed only if you can ensure no code injection and you have a<br>
> trusted code base.<br>
><br>
> > A process model for RTEMS makes no sense. For this you better use a micro kernel or Linux.</p>
<p dir="ltr">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?</p>
<p dir="ltr">Thanks,</p>
<p dir="ltr">  Daniel.</p>
<p dir="ltr">> ><br>
> > 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.<br>
> ><br>
> > For one customer we implemented a stack protection, a thread can only access its own stack, but this is quite non-standard.<br>
> ><br>
> >><br>
> >> We also saw this:<br>
> >><br>
> >> <a href="https://devel.rtems.org/wiki/Projects/MMU_Support">https://devel.rtems.org/wiki/Projects/MMU_Support</a><br>
> >><br>
> >> What's the status of this project?<br>
> ><br>
> > I don't know. MMU support tends to be highly architecture specific, so the development of a general purpose API is quite difficult.<br>
> ><br>
> I am (as we speak) working on a proposal to look in this direction.<br>
> I'm happy to talk more or to consider how to align our efforts.<br>
><br>
> >><br>
> >> On the other hand, we noticed that LEON3 IP Cores usually implement an<br>
> >> MMU instead of just an MPU. Would it be feasible to support that?<br>
> ><br>
> > The GR740 has an IOMMU (chapter 17).<br>
> ><br>
> > <a href="http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf">http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf</a><br>
> ><br>
> > --<br>
> > Sebastian Huber, embedded brains GmbH<br>
> ><br>
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> > Phone   : +49 89 189 47 41-16<br>
> > Fax     : +49 89 189 47 41-09<br>
> > E-Mail  : sebastian.huber at <a href="http://embedded-brains.de">embedded-brains.de</a><br>
> > PGP     : Public key available on request.<br>
> ><br>
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</p>