Interested in GSoC 2017 Project: Memory Protection.

Wed Mar 22 15:27:35 UTC 2017

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

> Indeed, PowerPC code is somewhat developed, would you recommend if there
> are some specific features in PowerPC that I should revisit? As this is
> little confusing as some work has been done on exception handler, page
> tables, cache already, so what should I target next and what to modify
> first? Past developer of the PowerPC support might help if you would
> connect me to?
> ᐧ
>
> I've CC'd some of the folks who previously worked on this topic. So
perhaps they have input for you.

I think the important thing is that when we design a framework that it is
flexible enough to accommodate the many varieties of memory management
hardware.

> *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*
>
>  ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
>
> On Wed, Mar 22, 2017 at 8:29 PM, Gedare Bloom <gedare at rtems.org> wrote:
>
>>
>>
>> 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/971b3cb1/attachment-0002.html>