Memory protection in RTEMS

[Gedare Bloom]

On Thu, Apr 2, 2015 at 11:52 AM, Gedare Bloom <gedare at rtems.org> wrote:
> On Thu, Apr 2, 2015 at 11:47 AM, Tomasz Gregorek
> <tomasz.gregorek at gmail.com> wrote:
>> 2015-04-02 17:38 GMT+02:00 Gedare Bloom <gedare at rtems.org>:
>>>
>>> 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.
>>
>>
>> I'll let you know.
>> So far I've seen some commercial RTOS with MPU. At the moment we consider
>> even Linux so you can say that the selection process is at early stage.
>>
> Great. If you need hard RT you must avoid Linux. Even soft RT is iffy
> there. The only feasible way to do real-time memory protection is with
> a region-based approach using MPU/segmentation like I wrote on my
Edit: You can use pages too, but you probably need super-pages (or
fairly small data requirements per thread) with software-controlled
TLB to do it right.

Gedare

> blog, or to write some custom hardware mechanisms and roll-your-own.
> Anything else seems unlikely to me to achieve RT guarantees.
>
> Good luck!
> Gedare
>
>> Tomasz
>>
>>>
>>> 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
>>> >
>>> >
>>
>>