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
