Memory Protection (Attributes)

Julien Delange julien.delange at gmail.com
Mon Dec 5 22:28:34 UTC 2011


On Mon, Dec 5, 2011 at 10:43 PM, Gedare Bloom <gedare at gwmail.gwu.edu> wrote:
> [snip]

I agree, this can be useful for security/safety reasons. But on the
other hand, I don't know if this really fits with the initial RTEMS
guidelines. RTEMS was designed (as far as I understood so far) as a
very lightweight executive for embedded systems. Such systems does not
have (most of the time) memory protection mechanisms.

So, introducing memory protection would be probably part of something
that is more in an upper upper layer, as the one provided by XtratuM
or AIR, which virtualize several RTEMS instances (that is more or less
the isolation layer of ARINC653). This approach keeps the minimal
RTEMS without memory protection and separates each RTEMS instance
according to the level of security/safety of each instance. Making
such layer (a separation layer/RTEMS virtualization layer) would not
break the initial guidelines described before.

On the other hand, by implementing memory protection in RTEMS core
API, you will also need to separate code execution in different levels
(such as ring0/ring3 on x86), and thus, will introduce a new level of
complexity (in terms of configuration for example) that is probably
not in the RTEMS guidelines (and cannot be implemented on all
architectures also).

Of course, this is just a comment/suggestion and I am interested in
that topic because such an evolution is a major step that must be
discussed (and so, congratulation for initiating this thread :-)

Greetings,



More information about the devel mailing list