Project for GSoC 2020

Mon Mar 2 16:04:11 UTC 2020

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

--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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200302/681ef049/attachment-0001.html>