Interested in GSoC 2017 Project: Memory Protection.

Fri Mar 24 19:07:05 UTC 2017

Work on shaping your proposal document and start to plan the work you would
do during the summer. This is the best way for me to collaborate is if you
begin writing out your ideas in sufficient detail that I can understand and
provide feedback based on where you are at.

On Fri, Mar 24, 2017 at 11:26 AM, Abhimanyu Rawat <
h2015081 at pilani.bits-pilani.ac.in> wrote:

> Hello Dr. Bloom,
>
> I have contacted to the past contributors,  Peter and I will discuss
> PowerPC and further support, next week, in the meantime, I am going through
> PowerPC code and how I can build with the existing system a new bsp code
> for MMU/MPU support. I will complete my application next week.
>
> In the meantime, any suggestions from your side are most welcome.
>
>
> On Wed, Mar 22, 2017 at 8:57 PM, Gedare Bloom <gedare at rtems.org> wrote:
>
>>
>>
>> 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/20170324/f0b7dc58/attachment-0002.html>