Memory Protection (Attributes)

Mon Dec 5 22:02:07 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.
>
>> 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
http://code.google.com/p/gsoc2011-rtems-mmu-support-project/source/browse/trunk/rtems/cpukit/libmmu/libmmu.c

>> 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