Re: Memory protection on RTEMS?

[Peter Dufault]

> On Sep 9, 2015, at 19:02 , Joel Sherrill  wrote:
> 
> 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.

I’ve worked on multi-processor systems with this attribute and I think it’s a 
good option, stack was private and “cheap” in terms of overhead on a processor. 
 If you use shared memory semantics you'll have portable code that works on 
multi-process (process, not processor) systems, it requires a little more 
design formalism up front.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Memory protection on RTEMS?

[Joel Sherrill]

On September 10, 2015 2:37:35 AM CDT, Peter Dufault  wrote:
>
>> On Sep 9, 2015, at 19:02 , Joel Sherrill 
>wrote:
>> 
>> 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.
>
>I’ve worked on multi-processor systems with this attribute and I think
>it’s a good option, stack was private and “cheap” in terms of overhead
>on a processor.  If you use shared memory semantics you'll have
>portable code that works on multi-process (process, not processor)
>systems, it requires a little more design formalism up front.

I don't think this is a huge issue to avoid in application code. The only 
common case I can think of is RTEMS calls writing status and messages back into 
stack variables as part of unblocking a task. 

My main point was that it would be good to take a holistic view and try to do 
the best for each type of memory object. Otherwise we end up potentially 
missing an opportunity or with an odd design limit because we focused on a 
specific implementation and application. 

>Peter
>-
>Peter Dufault
>HD Associates, Inc.  Software and System Engineering

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Memory protection on RTEMS?

[Hesham ALMatary]

On Thu, Sep 10, 2015 at 12:02 AM, Joel Sherrill
 wrote:
>
>
> On 9/9/2015 5:27 PM, Daniel Gutson wrote:
>>
>>
>> El 9/9/2015 16:14, "Gedare Bloom" > > escribió:
>>  >
>>  > On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
>>  > > > wrote:
>>  > > Hello Martin,
>>  > >
>>  > > - Martin Galvan > > 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 

Re: Memory protection on RTEMS?

[Daniel Gutson]

El 9/9/2015 16:14, "Gedare Bloom"  escribió:
>
> On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
>  wrote:
> > Hello Martin,
> >
> > - Martin Galvan  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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Memory protection on RTEMS?

[Joel Sherrill]

On 9/9/2015 5:27 PM, Daniel Gutson wrote:


El 9/9/2015 16:14, "Gedare Bloom" > 
escribió:
 >
 > On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
 > > wrote:
 > > Hello Martin,
 > >
 > > - Martin Galvan > 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 
 > > 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.comOn-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

Re: Memory protection on RTEMS?

[Sebastian Huber]

Hello Martin,

- Martin Galvan  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?

A process model for RTEMS makes no sense. For this you better use a micro 
kernel or Linux.

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.

> 
> 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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Memory protection on RTEMS?

[Gedare Bloom]

On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
 wrote:
> Hello Martin,
>
> - Martin Galvan  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.
>
> 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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Memory protection on RTEMS?

[Martin Galvan]

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?

We also saw this:

https://devel.rtems.org/wiki/Projects/MMU_Support

What's the status of this project?

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?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel