MMU was Re: Contribute to a project under GSOC 2018

[Gedare Bloom]

On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain <jainab.2009 at gmail.com> wrote:
> Sir,
>
> Thanks for your time and consideration. I was discussing this project with
> Gedare Sir and he guided me, how to proceed.
> I am studying various things before proceeding with the code part but for
> now, I request you to please guide me what should be my next steps to work
> on this project under GSOC'18.
>
> Thanks and Regards
> Abhinav Jain
>
> On Sun, Mar 4, 2018 at 10:48 AM, Hesham Almatary <heshamelmatary at gmail.com>
> wrote:
>>
>> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill <joel at rtems.org> wrote:
>> >
>> >
>> > On Mar 3, 2018 12:16 PM, "Abhinav Jain" <jainab.2009 at gmail.com> wrote:
>> >
>> > Sir/Madam,
>> >
>> > I am Abhinav Jain, a second-year engineering student from Delhi, India.
>> > I
>> > have been working in Linux Kernel Development, I have been writing small
>> > drivers and have a good knowledge of the operating system.
>> > I have been studying about Memory Protection project(ticket #2904) for
>> > around a month and found it really interesting. I studied about POSIX,
>> > MMU
>> > support in various other architecture and the memory protection APIs in
>> > various operating systems.I have been discussing the same on the mailing
>> > list.
>> > I also solved an issue (#2522) around a week ago to gain some hands-on
>> > code.
>> >
-ENOPATCH

>> >
>> > Welcome aboard.
>> >
>> >
>> > I would like to work on the Memory Protection project under GSOC 2018,
>> > so I
>> > request you to please guide me regarding the steps to be followed.
>> >
>> >
>> > Gedare conceived of what's there be so I cc'ed him. My recollection is
>> > that
>> > there were specific things he wanted to change and when that was
>> > addressed,
>> > providing support for arenas on multiple architecture is desirable
>> >
>> +1
>>
>> There might be an opportunity to port RTEMS to RISC-V's Supervisor
>> Mode which will need MMU support (currently it only runs on M-Mode
>> which doesn't have MMU). Both QEMU and Spike simulators support
>> S-Mode.
>>
Start to develop a draft proposal if you have not yet, starting with
our template. A successful proposal must contain a sound design and
good plan, which you will need a lot of time and feedback to develop.

Don't read too much about 64-bit processor architectures and their
needs, since we have limited support there. The first issue to resolve
is what kind of BSP-level interface should we provide over MMU/MPU
hardware, and then what can we do to use that BSP layer to provide
upper-layer services such as managed memory regions, better mmap()
support, "arena" allocators, etc. There are three views here:
1. no mmu/mpu is available or it is not desired by end users.
2. mmu/mpu are available, but should only be manipulated statically/boot-time.
3. mmu/mpu are available, and can be changed dynamically.

Managing #3 is the hardest, but accommodating 1 and 2 in any system
design is important. Another important concern is mmu/mpu with limited
numbers of entries. Right now, we exist mainly in #1, and #2 is only
used to setup a linear 1:1 memory map with all permissions enabled
when the MMU/MPU can't be turned off. A few projects exist here and
there to also restrict permissions to thread stacks with a hook in the
context switch to change the mpu/mmu state.

Since RTEMS has no multi-process model, the existing solutions in
general-purpose commodity OS do not apply, but you should still be
familiar with how they work for sure. It would also be good for you to
review the solutions in the commodity RTOS domain, e.g. what does
vxworks, safertos, threadx, etc., provides in this field.

Some relevant citations to get more relevant background:

https://highintegritysystems.com/downloads/white_papers/Using_an_MPU_to_Enforce_Spatial_Separation.pdf

https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3744f1f.pdf

https://www.researchgate.net/publication/221033285_A_New_Approach_to_Memory_Partitioning_in_On-Board_Spacecraft_Software




>> >
>> >
>> > Thanks and Regards
>> > Abhinav Jain
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Hesham
>
>