MMU was Re: Contribute to a project under GSOC 2018

Tue Apr 3 19:17:36 UTC 2018

Sir,

I have gone through https://homes.cs.washington.edu/~levy/opal/opal-tocs.pdf,
where the protection approach in Opal Operating System is provided. As per
my understanding of the paper, I have tried to extract the memory
protection part and have written a blog on it:
http://ajrealtime.blogspot.in/2018/04/sharing-and-protection-in-single.html
.
Opal is a single-address-space operating system, and in this paper, a
detailed description of protection is provided which I found quite useful
for getting a good idea which can be implemented in RTEMS too.
I request you to please have a look at the write-up written by me after
understanding this paper and also please guide me what should be my next
step to proceed with the project.

Thanks and Regards
Abhinav Jain

On Sat, Mar 24, 2018 at 12:36 AM, Abhinav Jain <jainab.2009 at gmail.com>
wrote:

> Sir,
>
> I have researched about the current MMU support available in RTEMS and I
> have mentioned about it in the proposal. Also as per your guidance, I have
> omitted the idea of developing memory protection for architectures not
> having MMU, rather I will give my full focus to developing MMU support for
> RISC -V architecture.
> I request you to please review the proposal and guide me if some changes
> are to be made to this, or if I should work on some other architecture. I
> am researching more about the difference in MMU in RISC -V and PowerPC and
> ARM, for which the MMU support is already available in RTEMS.
>
> https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OFJTvWK
> zWDXj1EvuEuq5o/edit?usp=sharing
>
> Thanks and Regards
> Abhinav Jain
>
>
> On Sat, Mar 17, 2018 at 1:29 PM, Abhinav Jain <jainab.2009 at gmail.com>
> wrote:
>
>> Sir,
>>
>> Thanks for the guidance and feedback. I have shared the draft proposal
>> through GSoC application. I will make the changes as per your suggestions
>> and will add the details mentioned by you.
>>
>> Thanks and Regards
>> Abhinav Jain
>>
>> On Sat, Mar 17, 2018 at 12:47 AM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> high-level comments:
>>>
>>> * add citations to relevant literature that you used for inspiration.
>>> * start to write a design plan for the bsp-level framework you envision.
>>> * it would be a good idea to review the existing mmu support in RTEMS.
>>> * link to this google doc as your "Draft" from your GSoC application,
>>> and also upload an initial "Final" pdf, which you can continue to
>>> revise.
>>>
>>> Gedare
>>>
>>> On Fri, Mar 16, 2018 at 2:48 PM, Abhinav Jain <jainab.2009 at gmail.com>
>>> wrote:
>>> > Sir,
>>> >
>>> > I have prepared a draft proposal for GSoC 2018 as suggested by you.
>>> > I request you to please guide me whether I have made it correctly or
>>> not,
>>> > whether I have written some big plans or more things can be included.
>>> >
>>> > The link for the Proposal is:
>>> > https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OF
>>> JTvWKzWDXj1EvuEuq5o/edit?usp=sharing
>>> >
>>> > Thanks and Regards
>>> > Abhinav Jain
>>> >
>>> > On Wed, Mar 14, 2018 at 10:47 PM, Abhinav Jain <jainab.2009 at gmail.com>
>>> > wrote:
>>> >>
>>> >> Sir,
>>> >>
>>> >> Thanks for the guidance. I am studying ARM architecture and trying to
>>> find
>>> >> out the difference in it's architecture from other ones, I am trying
>>> to
>>> >> understand what can be the minimum changes to the existing framework
>>> to get
>>> >> it working on other architectures.
>>> >>
>>> >> Thanks and Regards
>>> >> Abhinav Jain
>>> >>
>>> >>
>>> >> On Wed, Mar 14, 2018, 10:41 PM Gedare Bloom <gedare at rtems.org> wrote:
>>> >>>
>>> >>> The framework exists in the rtems source code, underneath
>>> >>> c/src/lib/libbsp/arm.
>>> >>>
>>> >>> Start with the GSoC template, adjust the dates, start adding details.
>>> >>> When you have a draft you can invite comments for review.
>>> >>>
>>> >>> On Wed, Mar 14, 2018 at 12:18 PM, Abhinav Jain <
>>> jainab.2009 at gmail.com>
>>> >>> wrote:
>>> >>> > Sir,
>>> >>> >
>>> >>> > The description of the RoadRunner OS is mentioned in the document
>>> >>> > provided
>>> >>> > by you,
>>> >>> >
>>> >>> > https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be
>>> 9b7591b3744f1f.pdf
>>> >>> > The link (http://ieeexplore.ieee.org/document/7509439/?part=1)
>>> which I
>>> >>> > mentioned in the previous mail deals with memory management scheme
>>> for
>>> >>> > the
>>> >>> > MMU-less embedded systems.
>>> >>> > If there is already a framework for ARM MMU, I will try to extend
>>> it to
>>> >>> > other architectures as much as possible, I read about various
>>> >>> > architectures
>>> >>> > in past couple of days.
>>> >>> > I request you to please provide the link to the available
>>> framework so
>>> >>> > that
>>> >>> > I can study that and proceed with its enhancement if possible.
>>> Also, I
>>> >>> > request you to please guide me for my GSoC proposal.
>>> >>> >
>>> >>> > Thanks and Regards
>>> >>> > Abhinav Jain
>>> >>> >
>>> >>> > On Wed, Mar 14, 2018 at 9:37 PM, Gedare Bloom <gedare at rtems.org>
>>> wrote:
>>> >>> >>
>>> >>> >> Abhinav,
>>> >>> >>
>>> >>> >> Send me the linked article. Does it describe the RoadRunner OS
>>> >>> >> approach? I am not familiar with it.
>>> >>> >>
>>> >>> >> Note that there is a basic framework for ARM MMU in place already.
>>> >>> >> Adoption/adaptation of it to other architectures is preferred
>>> versus
>>> >>> >> replacing it, unless absolutely necessary.
>>> >>> >>
>>> >>> >> On Wed, Mar 14, 2018 at 12:03 PM, Abhinav Jain <
>>> jainab.2009 at gmail.com>
>>> >>> >> wrote:
>>> >>> >> > Sir,
>>> >>> >> >
>>> >>> >> > I studied the documents provided by you in the previous mail,
>>> also I
>>> >>> >> > read a
>>> >>> >> > document from http://ieeexplore.ieee.org/doc
>>> ument/7509439/?part=1.
>>> >>> >> > As told by you in the previous mail that the first issue to be
>>> >>> >> > solved is
>>> >>> >> > to
>>> >>> >> > provide a BSP-level framework for MMU/MPU hardware, after
>>> reading
>>> >>> >> > the
>>> >>> >> > memory
>>> >>> >> > protection in roadrunner operating system, I think that with
>>> some
>>> >>> >> > changes,
>>> >>> >> > the same concept can be implemented in the RTEMS for memory
>>> >>> >> > protection.
>>> >>> >> > I request you to please guide me whether I am right in the
>>> approach
>>> >>> >> > or I
>>> >>> >> > have to think differently.
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > Thanks and Regards
>>> >>> >> > Abhinav Jain
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > On Wed, Mar 7, 2018 at 10:49 AM, Abhinav Jain
>>> >>> >> > <jainab.2009 at gmail.com>
>>> >>> >> > wrote:
>>> >>> >> >>
>>> >>> >> >> Sir,
>>> >>> >> >>
>>> >>> >> >> Thanks a lot for the guidance. I will study the documents
>>> provided
>>> >>> >> >> by
>>> >>> >> >> you
>>> >>> >> >> and will try to find more about this to increase my knowledge
>>> about
>>> >>> >> >> Memory
>>> >>> >> >> support.
>>> >>> >> >> I will start preparing a draft proposal as per the template
>>> >>> >> >> provided on
>>> >>> >> >> the RTEMS GSoC page.
>>> >>> >> >>
>>> >>> >> >> Thanks and Regards
>>> >>> >> >> Abhinav Jain
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> On Mar 6, 2018 10:25 PM, "Gedare Bloom" <gedare at rtems.org>
>>> wrote:
>>> >>> >> >>
>>> >>> >> >> 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/Usin
>>> g_an_MPU_to_Enforce_Spatial_Separation.pdf
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be
>>> 9b7591b3744f1f.pdf
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> https://www.researchgate.net/publication/221033285_A_New_App
>>> roach_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
>>> >>> >> >> >
>>> >>> >> >> >
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >
>>> >>> >
>>> >>> >
>>> >
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180404/a50cef25/attachment-0001.html>