Interested in GSoC 2017 Project: Memory Protection.

Abhimanyu Rawat h2015081 at pilani.bits-pilani.ac.in
Wed Mar 22 14:07:13 UTC 2017


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

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/33b139c3/attachment-0001.html>


More information about the devel mailing list