Memory Protection (Attributes)

Mon Dec 5 21:04:20 UTC 2011

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