I suspect that the same set of APIs won't work across all architectures and they would need to be implemented individually for each of them and a separate set of documentation would have to be provided for all the architectures for which the solution is implemented. If this is not implementable for the length of GSoC can I take up this ticket <https://devel.rtems.org/ticket/3222> as I believe I have a fair idea of how I can implement it and it seems doable for the length of GSoC.
On Sun, Mar 8, 2020 at 10:06 AM Gedare Bloom <ged...@rtems.org> wrote: > On Sat, Mar 7, 2020 at 12:00 AM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > > > > Sorry for the late reply, I was busy with my college tests. > > > > I looked into the MMU implementation of a few other RTOSs and zephyr > RTOS has an interesting memory domain implementation for thread stack > protection. Basically, the threads are grouped into memory domains as > 'struct memory_domain'. Each memory domain has 'struct memory_partition' > which contains the starting address, size and access policy for each > partition the 'memory_domain' also contains APIs to add/remove the memory > partition. Can this be implemented? I am not sure about the POSIX > compliance of this implementation. > > > > As was pointed out, a lot of the implementation in this project will be > architecture-specific. Would it be feasible to take up the implementation > for a particular architecture(specifically ARM or x86 as I have knowledge > about their architecture ) as a GSoC project? > > > Probably. But any design has to accommodate the many different kinds > of MMU/MPU support that are avialable, and should also work when there > is no support (maybe with a warning or an error if an application > tries to configure thread stack protection for an unsupported > architecture/BSP). > > > > > On Mon, Mar 2, 2020 at 10:55 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> > >> ----- Am 2. Mrz 2020 um 17:44 schrieb Gedare Bloom ged...@rtems.org: > >> > >> > On Mon, Mar 2, 2020 at 9:37 AM Joel Sherrill <j...@rtems.org> wrote: > >> >> > >> >> > >> >> > >> >> On Mon, Mar 2, 2020 at 10:12 AM Gedare Bloom <ged...@rtems.org> > wrote: > >> >>> > >> >>> On Mon, Mar 2, 2020 at 9:05 AM Joel Sherrill <j...@rtems.org> > wrote: > >> >>> > > >> >>> > > >> >>> > > >> >>> > On Mon, Mar 2, 2020 at 9:33 AM Gedare Bloom <ged...@rtems.org> > wrote: > >> >>> >> > >> >>> >> On Sat, Feb 29, 2020 at 2:58 PM Utkarsh Rai < > utkarsh.ra...@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! > >> >> > >> >> > >> >> Yep. Pushing this to the limit could break code in weird, hard > >> >> to understand ways. The fault handler may have to give a hint. :) > >> >> > >> >>> > >> >>> It may eventually be worth considering (performance-degrading) > >> >>> extensions to the API that copy buffers between thread contexts. > >> >> > >> >> > >> >> This might be challenging to support everywhere. Say you have > mmu_memcpy() > >> >> or whatever. It has to be used inside code RTEMS owns as well as > code that > >> >> RTEMS is leveraging from third party sources. Hopefully you would at > least > >> >> know the source thread (running) and destination thread easily. > >> >> > >> > > >> > This brings up the interesting design point, which may have been > >> > mentioned elsewhere, that is to group/pool threads together in the > >> > same protection domain. This way the application designer can control > >> > the sharing between threads that should share, while restricting > >> > others. > >> > >> Some years ago I added private stacks on Nios II. The patch was > relatively small. I think the event and message queue send needed some > adjustments. Also some higher level code was broken, e.g. structures > created on the stack with some sort of request/response handling (bdbuf). > Doing this with a user extension was not possible. At some point in time > you have to run without a stack to do the switching. > >> > >> On ARMv7-MR it would be easy to add a thread stack protection zone > after the thread stack via the memory protection unit. > >> > >> On a recent project I added MMU protection to the heap (ARM 4KiB > pages). You quickly get use after free and out of bounds errors with this. > The problem is that each memory allocation consumes at least 4KiB of RAM. > >> > >> I am not sure if this area is good for GSoC. You need a lot of > hardware-specific knowledge and generalizations across architectures are > difficult. >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
