Memory Protection (Attributes)

Sat Dec 10 23:44:51 UTC 2011

On Mon, Dec 5, 2011 at 4:04 PM, Gedare Bloom <gedare at rtems.org> wrote:
> On Mon, Dec 5, 2011 at 3:30 PM, Thomas Doerfler
> <Thomas.Doerfler at embedded-brains.de> 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
>>
>> http://gedare-csphd.blogspot.com/2011/12/rtems-memory-protection-api.html
>>
>> 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.
>
I will change "bounds" to "size" (bytes).

>> 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.
>
I still do not have great ideas for naming. Also, I should probably
implement these structures at the SCORE level and, if desired, export
the structures at the user API level. Still the cumbersome naming will
be an issue, the straightforward translation is:
_Memory_protection_Region (drop "descriptor")
_Memory_protection_Attributes (was permissions)
_Memory_protection_Entry
_Memory_protection_Domain

These seem like reasonable names to me. Some viable alternatives:
_Mprotect_Xxx -- aligns with posix-y memory protection
_Mprotection_Xxx
_Protection_Xxx

>> 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?
>>
This might be worth thinking over when looking at how the various
memory-related data structures are implemented.

>> 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?
>
At the SCORE level the Region name is available. If I move most of the
implementation to within the SCORE and consider how to adopt existing
APIs to allow optional memory protection then the name conflict might
go away.

>> 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 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]
>>> http://gedare-csphd.blogspot.com/2011/12/rtems-memory-protection-api.html
>>>
>>>
>> [2] http://www.rtems.org/pipermail/rtems-devel/2011-December/000004.html
>>> _______________________________________________ rtems-users mailing
>>> list rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>> --
>> --------------------------------------------
>> Embedded Brains GmbH
>> Thomas Doerfler           Obere Lagerstr. 30
>> D-82178 Puchheim          Germany
>> email: Thomas.Doerfler at embedded-brains.de
>> Phone: +49-89-18908079-2
>> Fax:   +49-89-18908079-9
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel