Memory protection in RTEMS

Thu Apr 9 20:25:03 UTC 2015

The kind of memory protection I'd like to see would require coding changes to the way traditional single address space real-time systems work, but I don't think it would affect performance.  I'd like to be able to use a system where:

- Stack and "normally" allocated memory would be per-thread;
- Memory shared between threads would need to be specified in a special (but standard conferment) way.

All read-only items would be shared between all threads.  Stack and  normally-allocated heap (i.e., c++ new and malloc()) would be per-thread and couldn't be shared.  A pointer that points to something shared between threads would need to be specified using (one possibility, I'm sure there are other standard ways) a POSIX shared memory interface.

Since it is likely that there are a limited number of MMU contexts in an embedded controller you'd probably need to let most threads exist as they do now (living in a totally shared address space) and choose some threads to exist in the more protected environment.

This model assumes you have a single global shared memory domain (what exists now in most real-time systems) together with a per-thread private memory domain that is only valid when a specific thread is executing.  That's has to be low-overhead at context switch time for this to work.

There are other issues to sort out - the granularity of the MMU regions is going to affect stack size for threads with protected stack, etc.

> On Apr 9, 2015, at 09:36 , Gedare Bloom <gedare at rtems.org> wrote:
> 
> Hi Mohammed,
> 
> Hardware support for memory protection is not uniform across processor
> architectures. Generally speaking, memory protection is
> non-deterministic, although some restrictions may be imposed to reduce
> the non-determinism by limiting the number of protected memory
> regions. Changing the protection domain when task-switching also
> greatly increases the system-level overhead for context switching,
> thus causing difficulty to WCET estimates and schedulability analysis.
> Furthermore, memory protection when enabled increases the average
> memory access time. Most real-time systems in the past have been
> "single-user, single-program, narrow networking" which precludes any
> real need for protection. Now we see multi-program, multi-user, and
> wide networking interfaces, and the need for memory protection is
> becoming more of an issue.
> 
> Gedare
> 
> On Thu, Apr 9, 2015 at 12:12 AM, Mohammed Saeed Khoory
> <Mohammed.Khoory at eiast.ae> wrote:
>> Hi,
>> 
>> I find this topic interesting as well. I've had a general question about memory protection that I was hoping someone knowledgeable could shed light on.
>> 
>> I've noticed that some RTOS's (not just RTEMS) don't implement memory protection and prefer to stay that way. I think real-time Linux also explicitly disables memory protection by having real-time tasks run in kernel mode. Is there something about memory protection that makes it disadvantageous to real-time computing in general? Does it introduce non-determinism? Or is it in order to reduce complexity, and maybe to keep the address space flat and simple?
>> 
>> Thanks!
>> 
>>> -----Original Message-----
>>> From: users [mailto:users-bounces at rtems.org] On Behalf Of Gedare Bloom
>>> Sent: Thursday, April 02, 2015 7:39 PM
>>> To: Tomasz Gregorek
>>> Cc: users at rtems.org
>>> Subject: Re: Memory protection in RTEMS
>>> 
>>> On Thu, Apr 2, 2015 at 11:19 AM, Tomasz Gregorek
>>> <tomasz.gregorek at gmail.com> wrote:
>>>> Hi Gedare
>>>> 
>>>> Thank you for your comments, they answer my question.
>>>> 
>>>> We will look at other RTOSes this time.
>>>> 
>>> OK, I'd be happy to hear what you find or settle on. It's a topic that I
>>> have continued interest in working on for RTEMS.
>>> 
>>> Gedare
>>> 
>>>> Thanks
>>>> Tomasz
>>>> 
>>>> 2015-04-02 17:01 GMT+02:00 Gedare Bloom <gedare at rtems.org>:
>>>>> 
>>>>> Hi Tomasz,
>>>>> 
>>>>> It is possible to implement some memory protection between threads.
>>>>> As you noticed, RTEMS is a SASOS with "one process" when viewed from
>>>>> the POSIX interface. Generalizing memory protection in such a system
>>>>> is hard. The most common approach I know of is to provide separate
>>>>> protection domains for each thread stack. In theory, you could create
>>>>> a protection domain for the RTEMS "kernel", but I'm not aware of
>>>>> anyone that has tried hard to do that. You may also look for the
>>>>> "Zero Kernel" work some folks did as a research project at Univ of
>>>>> Idaho I think it was.
>>>>> 
>>>>> If you want memory protection, you'd have to tailor it to your
>>>>> specific application requirements and set-up the MMU/MPU to do it.
>>>>> Final note: Since there is no notion of privilege in RTEMS, any
>>>>> thread can always disable or modify the protection domains since
>>>>> priviliged registers and instructions are available. Thus, while you
>>>>> may add memory protection, it would not be for a complete security
>>> solution.
>>>>> 
>>>>> Gedare
>>>>> 
>>>>> On Thu, Apr 2, 2015 at 10:04 AM, Tomasz Gregorek
>>>>> <tomasz.gregorek at gmail.com> wrote:
>>>>>> Hi
>>>>>> 
>>>>>> We are investigating possible OSes for a new product where one of
>>>>>> the requirements is memory protection between processes.
>>>>>> 
>>>>>> Does RTEMS supports memory protection? If not than is it planned to
>>>>>> implement memory protection?
>>>>>> 
>>>>>> This is what I found so far:
>>>>>> 
>>>>>> RTEMS is single process, multiple threads and as such have
>>>>>> everything in single memory space.
>>>>>> http://comments.gmane.org/gmane.os.rtems.user/19858
>>>>>> 
>>>>>> Gedare's blog with his implementation of memory protection from
>>>>>> 2011/2012.
>>>>>> http://gedare-csphd.blogspot.be/2011/12/rtems-memory-protection-api
>>>>>> .html but it seems that this code didn't get to the main.
>>>>>> 
>>>>>> Project "MMU Support" by Aanjhan Ranganathan from 6 years ago:
>>>>>> https://devel.rtems.org/wiki/Projects/MMU_Support
>>>>>> 
>>>>>> Source code configures MMUs but it seems it do it to enable cache
>>>>>> only, not the memory protection. Though I did only simple search
>>>>>> through the code.
>>>>>> There are exception handlers for some architectures/CPUs but only
>>>>>> for few if not for only one.
>>>>>> 
>>>>>> Best regards
>>>>>> Tomasz Gregorek
>>>>>> 
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> users at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/users
>>>> 
>>>> 
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users

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