Interested in GSoC 2017 Project: Memory Protection.

Fri Mar 17 15:55:10 UTC 2017

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.

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.

> 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/20170317/9e8b7821/attachment-0002.html>