Project for GSoC 2020

Mon Mar 2 16:12:07 UTC 2020

On Mon, Mar 2, 2020 at 9:05 AM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Mon, Mar 2, 2020 at 9:33 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Sat, Feb 29, 2020 at 2:58 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>> >
>> > I have gone through the details of the project adding memory protection using MMU and have a few questions and observations regarding the same-
>> >
>> > 1. Is this a project for which someone from the community would be willing to mentor for GSoC?
>>
>> Yes, Peter Dufault has expressed interest. There are also several
>> generally interested parties that may like to stay in the loop.
>>
>> > 2. As far I could understand by looking into the rtems tree ARM uses static initialization wherein it first invalidates the cache and TLB blocks and then performs initialization by setting up a 1 to 1 mapping of the parts of address space. According to me, static initialization of the mmu is a generic enough method that can be utilized in most of the architectures.
>>
>> Yes, it should be. That is how most architectures will do it, if they
>> need to. Some might disable the MMU/MPU and not bother, then there is
>> some work to do to figure out how to enable the static/init-time
>> memory map.
>>
>> > 3. For the thread stack protection, I believe either of the stack guard protection approach or by verification of stack canaries whereby the OS on each context switch would check whether the numbers associated with the canaries are still intact or not are worth considering. Although I still only have a high-level idea of both of these approaches and will be looking into their implementation details, I would request your kind feedback on it.
>> >
>>
>> Thread stack protection is different from stack overflow protection.
>> We do have some stack overflow checking that can be enabled. The
>> thread stack protection means you would have separate MMU/MPU region
>> for each thread's stack, so on  context switch you would enable the
>> heir thread's stack region and disable the executing thread's region.
>> This way, different threads can't access each other's stacks directly.
>
>
> FWIW the thread stack allocator/deallocator plugin support was originally
> added for a user who allocated fixed size stacks to all threads and used
> the MMU to invalidate the addresses immediately before and after each
> stack area.
>
> Another thing to consider is the semantics of protecting a thread. Since
> RTEMS is POSIX single process, multi-threaded, there is an assumption
> that all data, bss, heap, and stack memory is accessible by all threads.
> This means you can protect for out of area writes/reads but can't generally
> protect from one thread accessing another thread's memory. This may

Right: thread stack protection must be application-configurable.

> sound like it doesn't happen often but anytime data is returned from a
> blocking call, the contents are copied from one thread's address space
> to another. Message queue receives are one example. I suspect all
> blocking reads do this (sockets, files, etc)
>
It should not happen inside rtems unless the user sends thread-stack
pointers via API calls, so the documentation must make it clear: user
beware!

It may eventually be worth considering (performance-degrading)
extensions to the API that copy buffers between thread contexts. But
yes, we are operating outside of POSIX.

> --joel
>>
>>
>> Gedare
>>
>> > Regards,
>> > Utkarsh Rai.
>> >
>> > On Fri, Feb 21, 2020 at 10:28 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>> >>
>> >> Thanks, I will check it out.
>> >>
>> >> On Fri, Feb 21, 2020 at 12:56 AM Gedare Bloom <gedare at rtems.org> wrote:
>> >>>
>> >>> On Tue, Feb 18, 2020 at 12:45 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>> >>> >
>> >>> > Based on your feedback,  adding memory protection or enhancing Wi-fi Support in libbsd are two projects that I would like to work upon.
>> >>> >
>> >>> > For MMU support I think a lot unmerged PowerPC code is already present, but since  I would be using BBB I would only be able to use that as a reference. Is it feasible to start it from scratch?
>> >>> >
>> >>> The state-of-the-art has advanced in the rtems.git tree since these
>> >>> projects happened, and it is not all documented. The ARM in particular
>> >>> generally uses a static initialization or boot-time initialization of
>> >>> the MMU. You  should study how the ARM approach works in the RTEMS
>> >>> main repo, and consider whether that approach can be adopted by other
>> >>> architectures/BSPs, how to improve that approach, and how to build
>> >>> higher-level services on top of the low-level BSP support that exists.
>> >>>
>> >>> One of the main interesting applications is to provide thread stack protection.
>> >>>
>> >>> > For Wi-Fi support, I would require an RTL8188 USB dongle along with JTAG for debugging purposes. I am not quite sure about how to handle the 'hot-plugging' case in this project it would be very helpful if someone could point me in the right direction.
>> >>> >
>> >>> I can't speak to the WiFi support, maybe others know. But to get
>> >>> started you would need to at least demonstrate that you have the
>> >>> necessary hardware to succeed and that you can at a minimum boot/run
>> >>> BBB with libbsd, and probably we should like you to show that you can
>> >>> generate patches for libbsd.
>> >>>
>> >>> Gedare
>> >>>
>> >>> >
>> >>> > On Tue, Feb 18, 2020 at 1:21 AM Gedare Bloom <gedare at rtems.org> wrote:
>> >>> >>
>> >>> >>
>> >>> >> On Mon, Feb 17, 2020 at 9:42 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>> >>> >>>
>> >>> >>> Hello everyone,
>> >>> >>
>> >>> >> Hello Utkarsh Rai,
>> >>> >>
>> >>> >>>
>> >>> >>> I would like to contribute to the Beagleboard BSP project, in particular towards the improvement of the peripheral support. I have a few questions pertaining to the same:-
>> >>> >>>
>> >>> >>> 1. Is adding support for Ethernet and USB a reasonable goal for the duration of the GSOC?
>> >>> >>>
>> >>> >>> 2. FreeBSD has support for Ethernet and USB  can we port that to libbsd?
>> >>> >>>
>> >>> >>> 3. What are the deliverables for this project, for instance, would I be required to add shell support for these peripherals or maybe an example app?
>> >>> >>>
>> >>> >>> I have also attached a screenshot of the changed  'hello world' program along with this email
>> >>> >>
>> >>> >> Thanks. It is nice to see that you already ran it successfully on the BBB.
>> >>> >>
>> >>> >> As of now, the BBB has quite mature support including Ethernet and USB. There is another student actively working on a proposal to expand our BBB support a bit further. I'm not certain if there is sufficient work/interest/mentoring available to support multiple BBB projects. You might consider what specific projects would interest you though. You should take a look at past years' GSoC projects documented on our wiki, they are linked from our main 'GSoC' page.
>> >>> >>
>> >>> >> There are also lots of interesting projects that can be done in a BSP-agnostic way, but still could be valuable to test with the BBB. The most important aspect about doing development with a BBB is that you can use the JTAG, which requires some soldering and additional effort to work with a standalone JTAG debugger.  If you don't have that, and want to work with the BBB, it is highly recommended.
>> >>> >>
>> >>> >>
>> >>> >>>
>> >>> >>> _______________________________________________
>> >>> >>> devel mailing list
>> >>> >>> devel at rtems.org
>> >>> >>> http://lists.rtems.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel