Interested in GSoC 2017 Project: Memory Protection.

Wed Mar 22 14:59:20 UTC 2017

On Wed, Mar 22, 2017 at 10:07 AM, Abhimanyu Rawat <
h2015081 at pilani.bits-pilani.ac.in> wrote:

>
> On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom <gedare at rtems.org> wrote:
>
>> Please prefer to try to keep general GSoC / RTEMS project discussions on
>> the mailing list. Direct e-mail is ok but inefficient in many cases and
>> should only be preferred for communciations of a personal or private matter.
>>
>> On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat <
>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>
>>>
>>> On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat <
>>>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>>>
>>>>> Hello Dr. Bloom,
>>>>>
>>>>> Sorry for writing after a big gap( was busy with a product
>>>>> integration), although I found time to go through the pointers you put
>>>>> together for me, thanks they were really helpful in getting an idea about
>>>>> the project and how to process everything in time.
>>>>>
>>>>> Gaps are normal and acceptable (until you are getting paid for work
>>>> :)). You should also expect to have gaps in responses from developers on
>>>> the mailing list, since we are also generally volunteering.
>>>>
>>>>
>>>>> I noticed that all the existing work on MMU is not moving very fast
>>>>> like other supporting components for RTEMS, last year too no one was
>>>>> selected to do MMU project #2904. I know only one guy applied but the
>>>>> proposal was not quite promising. But trust me, all that doesn't make it
>>>>> any less desirable for me to take it. Now, I have a few questions:
>>>>>
>>>>> I would not recommend judging the priority/value of a proposed project
>>>> based on whether or not it was done in the past. Definitely discuss with
>>>> mentors, etc. This project area is a good, long-term investment for RTEMS,
>>>> but it does move slowly.
>>>>
>>>>
>>>>>
>>>>> On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom <gedare at rtems.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat <
>>>>>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>>>>>
>>>>>>> Hello folks,
>>>>>>>
>>>>>>> I am Abhimanyu Rawat, a Computer Science Masters degree student from
>>>>>>> BITS Pilani Campus, India. I found Memory Protection project #2904
>>>>>>> <https://devel.rtems.org/ticket/2904> very interesting and vital
>>>>>>> for the the RTEMS. Among the lots of projects listed on the ideas page,
>>>>>>> Memory Protection draws me to RTEMS as it's a very challenging project and
>>>>>>> I would thoroughly enjoy working on it. I am a really enthusiastic person
>>>>>>> who would like to contribute to the project. I have previous experience in
>>>>>>> C, C++ and Python etc.  At present I am an intern at EMC ^2 where I am
>>>>>>> working on DataDomain Operating system, building configuration tool for
>>>>>>> the latest DDOS software update. I have also lead a BITS-Stanford
>>>>>>> inter-university project, where my team worked on Django based project with
>>>>>>> an inbuilt authorization tool + chat application etc. I usually help my
>>>>>>> friends with their projects as well.
>>>>>>>
>>>>>>> When does your internship complete, and when does your school year
>>>>>> begin again?
>>>>>>
>>>>>>
>>>>>>> As required, I went through the initial brief about the project and
>>>>>>> I think it would be a valuable addition to RTEMS. Also, I have completed
>>>>>>> the https://devel.rtems.org/wiki/GSoC/GettingStarted, and
>>>>>>> configured and Built RTEMS for SPARC/erc32. Subsequently, I have the
>>>>>>> snapshot of the terminal showing my name and the GSOC text as pictured
>>>>>>> here
>>>>>>> <https://devel.rtems.org/attachment/wiki/GSoC/GettingStarted/SPARC-SIS-HelloWorld-Modded.png>.
>>>>>>> Kindly tell me how  selectively pointed towto send the proof of the
>>>>>>> terminal and the diff file as required.
>>>>>>>
>>>>>>> Send to me by email is fine.
>>>>>>
>>>>>>
>>>>>>> It would be great if you can give me some pointers about the
>>>>>>> structure of the project and the direction I should pursue.
>>>>>>>
>>>>>>> Have a look at the current approach taken to provide low-level
>>>>>> support for the MMUs in the ARM bsps. You can find this looking in the
>>>>>> source tree via c/src/lib/libbsp/arm/* with most of the relevant parts in
>>>>>> the shared subdirectory there, where each BSP defines a table of
>>>>>> statically-configured MMU initialization.
>>>>>>
>>>>>
>>>>> You selectively pointed towards the c/src/lib/libbsp/arm/* shared
>>>>> subdirectory where some BSP's has low level code for MMU configuration, I
>>>>> found ome cache code too. And trying digging deep to build a common
>>>>> understanding of different BSP MMU code. The code initally is quite hard to
>>>>> understand but as a unit what task is taking place is I can understand
>>>>> like, data cache and line cleaing etc. Therefore I would request you to
>>>>> provide me a documented code review or process guide( if available)
>>>>> so that I can develop something to test the MMU code changes/patches,
>>>>> otherwise I will have to brute force the search. As from this point I want
>>>>> to move fast and reflect the my progress.
>>>>>
>>>>>>
>>>>>>
>>>>> I recommend that you start by writing a blog post about your
>>>> understanding of what is implemented there. Look in the other BSPs to see
>>>> what, if any, MMU code they have.
>>>>
>>>> Sure, setting up a medium blog to write about the bsp underlying code
>>>  related to memory related operations.
>>>
>>>> Cache cleaning/invalidating is often tied with MMU state changes.
>>>>
>>>>
>>>>> This is where the prior work has pretty much left off. Remaining items
>>>>>> in this project area include:
>>>>>> * Making a uniform approach to MMU/MPU setup across architectures
>>>>>>
>>>>> It seems nice to have a low level design which can point out the
>>>>> mutual modules such as initialising the registers, stack and memory lines
>>>>> etc. For this I think underying functionality have to be completed first or
>>>>> complete the remaining pieces in existing code and then move bottom up.
>>>>>
>>>>>
>>>> The underlying functionality exists for at least cp15-based ARM.
>>>> Providing the functionality for another BSP family would be a good place to
>>>> start.
>>>>
>>>>
>>>>> * Supporting dynamic changes to MMU/MPU configurations
>>>>>> * Leveraging dynamic MMU/MPU enforcement to create a mid-level memory
>>>>>> management layers. Various proposals have been designed and implemented in
>>>>>> the past that can be studied.
>>>>>>
>>>>> When you say dynamic changes, it means application level memory
>>>>> proection, space quota management etc. ? I know you should be having a full
>>>>> list, so l am willing to hear all that and then decide which work should be
>>>>> done first and how I propose to do it.
>>>>>
>>>>>
>>>> Dynamic here means the MMU entries can be changed at run-time after
>>>> initialization. This is a building block for implementing higher-level
>>>> services such as application-level memory protection and kernel-level APIs
>>>> for memory management.
>>>>
>>>>
>>>>> * Creating generally useful memory protection schemes such as per-task
>>>>>> stack protection that can be enabled by applications with simple "switch it
>>>>>> on" type of logic.
>>>>>>
>>>>> * Creating an application-layer interface for memory protection
>>>>>> management at a finer granularity / with more application-level logic to
>>>>>> control than the "generally useful" approaches would need.
>>>>>>
>>>>>> Ok this is exciting stuff that can be pushed first, the memory block
>>>>> or segement(or whatever you say to a chunk but mostly I went through thesis
>>>>> material online which denotes it as in different terms/name ) access
>>>>> related control can be hacked together to provide the enclaved type of
>>>>> execution for the application task. We can discuss more about it and how
>>>>> much existing code base so far support this proposed project area.
>>>>>
>>>>> I prefer memory region to refer to a generic "Base+Offset" contiguous
>>>> area of memory. We have discussed terminology quite often in the past.
>>>> Reach out to Hesham to get some more details.
>>>>
>>>
>>>> We can't do application-level memory protection without a good
>>>> understanding of the intermediate layers. We can start to design an API,
>>>> but the API is not mergeable until there is a generic layer that is not
>>>> tightly bound to the BSP or even CPU layers.
>>>>
>>>
>>> In case of arm-cp15  it's underlying fucntionality are far more
>>> developed(i.e. initialization, interrupt handling, underlying tlb update
>>> after fage faults etc.) than the rest of the bsp's, so I think we can start
>>> to design an API for application-level memory protection. This way we can
>>> have atleast one fully functional bsp for arm-cp 15, whose prototype can we
>>> can later use to speed up the development  You think it can be a good
>>> proposal or shall I go with other bsp underlying support first?
>>>
>>>>
>>>>
>>> I'm concerned that any mid-level/high-level framework built on top of
>> the existing low-level support for arm-cp15 will be too rigid to work with
>> less feature-ful BSPs/MMU/MPU combinations. It would be good to have
>> another one or two kinds of MMU/MPU supported so that the upper layers can
>> be more thoughtfully designed.
>>
>>
>  I agree with your approach of having more than one type of bsp's with
> MMU/MPU support, so which one should I take on ? I mean I can work on
> AT91RM9200 of ARM family, or you would suggest other archiitecture
> like(PowerPC) ?
>
> PowerPC should be good. That was one of the targets worked on previously,
so it should not be too difficult.


> I look forward, to hear what is your take on them, and last but not the
>>>>> least, thanks for the warm reply, it already makes me feel home with the
>>>>> community.
>>>>>
>>>>>
>>>> Overall, I look forward to working with the community and improving my
>>>>>>> skills by actively contributing to the project(in long run also).
>>>>>>>
>>>>>>> *Closing with thank you and warm Regards,*
>>>>>>>
>>>>>>> *Abhimanyu Rawat*
>>>>>>> *M.E. Computer Science, *
>>>>>>> *CS/IS Department, BITS Pilani, Pilani Campus*
>>>>>>> *Email - h2015081 at pilani.bits-pilani.ac.in
>>>>>>> <h2015081 at pilani.bits-pilani.ac.in> / abhimanyurawat at yahoo.com
>>>>>>> <abhimanyurawat at yahoo.com>*
>>>>>>> *Phone. 08930399302 (call/Whatsapp), 09466899302*
>>>>>>>
>>>>>>>  ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
>>>>>>> ᐧ
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devel mailing list
>>>>>>> devel at rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>>
>>>>>>
>>>>>>
>>>>> ᐧ
>>>>>
>>>>
>>>>
>>>
>>
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170322/00224ebc/attachment-0001.html>