RFC - Memory Partitioning

[Charles Steaderman]

RFC

Memory Partitioning Support in RTEMS

Goals:
Provide task level code and memory partitioning for RTEMS. The short 
term goal would be for a project that contains functionality to be FAA 
certified at different certification levels (background data collection 
and storage certified to FAA Level C, and user interface non-certified).

Proposed Strategy:
Based upon some research into commercial partitioned embedded OSes 
(Integrity, Nucleus Secure, etc), I would like to suggest the following 
strategy for enhancing RTEMS. First, to provide separation from the 
kernel, I would propose that all RTEMS kernel calls be accessed via a 
TRAP or SWI. In this way, the kernel code can be mapped into a 
non-accessable memory area in order to provide protection from userland 
tasks. Second, I would propose that task creation and context switching 
become memory region aware. Task creation would need to be supplied 
memory regions and access permissions and those permissions would need 
to be updated on a context switch (MMU registers). In addition, each 
task could have its own private memory heap for dynamic memory 
allocation. This would mean that memory allocation would need to be told 
whether the allocation should come from the local or global heap.

I am sure that there is a large number of issues that I have overlooked, 
but I would like to get people thinking about partitioning in RTEMS. In 
much the same way that desktop operating systems have benefitted from 
process protectsion (Win9x vs. WinNT or OS 9 vs. OS X), I think that 
given the present and future state of embedded hardware, embedded 
systems could benefit from the same robustness. One advantage that I 
believe the proposed solution has is that the code resides in a single 
address space, rather than virtual memory spaces. Perhaps this will 
cause problems with library calls and shared code, but perhaps there is 
a novel solution that we could employ.

Thank you for your time and consideration.

- Charlie

-- 
Charlie Steaderman
charlies at poliac.com
VP Engineering
Poliac Research Corporation
Phone: 952.707.6245
Cell: 612.242.6364


-------------- next part --------------
A non-text attachment was scrubbed...
Name: charlies.vcf
Type: text/x-vcard
Size: 329 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20070723/c7533f86/attachment.vcf>