Memory Protection (Attributes)

Gedare Bloom gedare at
Mon Dec 5 22:02:07 UTC 2011

On Mon, Dec 5, 2011 at 4:04 PM, Gedare Bloom <gedare at> wrote:
> On Mon, Dec 5, 2011 at 3:30 PM, Thomas Doerfler
> <Thomas.Doerfler at> wrote:
>> Gedare,
>> so you made me subscribe to that list ;-) . Discussing your API
>> recommendation here makes sense. Getting a proper memory protection
>> API makes even more sense, and there were several attempts to get that
>> functionality.
>> I will give you my feedback without a particular order.
>> 1.) Just a minor: When I look at your page
>> I can see only part of the comments. The code window seems fixe width,
>> and not all of the code is visible. Maybe this is due to my private
>> browser settings.
> I haven't figured out a great way to present code snippets. The
> biggest issue is spacing, since html adjusts spacing dynamically it is
> hard to align indentation so I use the "pre" tag which I'm sure is
> causing most of the problems for your browser.
>> 2.) In structure rtems_memory_protection_region_descriptor I tripped
>> over the nama of the "bounds" member. I would expect this to be named
>> "size" or "length". Maybe this is de to my limited knowledge of
>> english ;-)
> I was going with the convention of "Base and Bounds" which is pretty
> well-known in the memory protection area, but perhaps just calling it
> "size" (in bytes) would be as simple.
>> 3.) The names used get very long. "memory_protection" is a rather long
>> word. Maybe abreviating it to "MP" would make sense? I am not really
>> sure about that...
> I would like a shorter name as well. I am rethinking this "protection"
> aspect since (as you say below) some of this code may apply in
> non-protection scenarios, namely just applying attributes to memory
> regions.
>> 4.) Your "memory_protection_region_descriptor" describes a memory
>> region. Maybe the same structure might be useful also in a
>> "non-protection" context. So I think a name "memory_region_descriptor"
>> would also match its use?
>> 5.) The term "region" already has a different meaning in the RTEMS
>> context, you know the "Classic API" object type "Region". UPS, and
>> here we have a collision with my recommendation in topic 4.
> Yes it would be good to come up with a name that (1) has no conflicts
> and (2) concisely captures the notion of a memory region.
> rtems_memory_range might be a good compromise?
>> My first comments are mainly about names, but proper names are
>> important to avoid confusion (in code and in the head).
> Naming is definitely important, especially in RTEMS where there is no
> namespace protection, so I appreciate the feedback.
>> 6.) I did not yet understand the context the memory protection will be
>> bound to. Are the installed MPDs valid for all tasks, or is it
>> possible to have MPDs that are only valid while a certain task is
>> active? Are the MPDs bound to a distinct core in a SMP system or to
>> all cores?
> I envision multiple MPDs including per-task, per-core, global/shared,
> and user-defined.  For per-task MPDs the context switch will be hooked
> to uninstall/install the enforced MPD. For user-defined MPDs the user
> code would define when to uninstall/install. There may be some global
> MPD that restricts the available memory regions for any task, then
> per-task MPDs / user MPDs would further refine the attributes on those
> memory regions. SMP should follow directly by having some global MPDs,
> some per-core MPDs (if the HW can support it), and per-task / user
> MPDs.
> I have not currently tested anything with multiple MPDs. I
> think we might reasonably get away with a small number of fixed
> "system-level" MPDs that are well-known to each other and can be
> turned on by users like flipping a switch (e.g. to protect tasks from
> each other). The middle layer will have to know about all the MPDs in
> existence to avoid conflicts, but we should be able to do that easily
> enough.
> So far I have only talked about how to specify kinds of memory ranges,
> permissions (attributes), and handles for userland. I will send out a
> description of the internals soon, in fact I think I will keep up the
> momentum and work on that now.
I have written up the middle-layer now. I have not entirely described
the implementation of the API layer however you can see the code at

>> I know you are at the start of the API definitions, but I think these
>> are questions to be discussed.
>> And I hope you will go on in this attempt, so don't get my partial
>> critics wrong. I think MP will be an important feature for realtime
>> systems in the future, so we need a proper, common, portable API in RTEMS.
> Thanks!
> Gedare
> - Hide quoted text -
>> wkr,
>> Thomas Doerfler.
>> Am 05.12.2011 20:02, schrieb Gedare Bloom:
>>> Hi, I am working to bring primitives for real-time memory
>>> protection to RTEMS, and as a first step I have designed a solution
>>> for setting/enforcing attributes on memory regions. The design is
>>> in three layers: a high-level API (cpukit) layer, a middle layer
>>> for CPU family support (libcpu), and a low-level layer for
>>> hardware-specific support (libcpu/libbsp).
>>> I have written a description of the API layer [1] and would
>>> appreciate any feedback. I prefer to have the feedback given
>>> publicly to the rtems-devel mailing list thread [2] (or privately
>>> to me directly).
>>> I will describe the other layers in the near future. -Gedare
>>> [1]
>> [2]
>>> _______________________________________________ rtems-users mailing
>>> list rtems-users at
>> --
>> --------------------------------------------
>> Embedded Brains GmbH
>> Thomas Doerfler           Obere Lagerstr. 30
>> D-82178 Puchheim          Germany
>> email: Thomas.Doerfler at
>> Phone: +49-89-18908079-2
>> Fax:   +49-89-18908079-9
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at

More information about the devel mailing list