Hi Utkarsh, You can remove "Discussion regarding" from your subject lines. We know your emails are discussions regarding the subject.
On Fri, Mar 27, 2020 at 5:26 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > Hi, > My GSoC project proposal intended for providing thread-stack protection > involves implementation on two levels, providing low-level hardware support > for the target architecture and high-level architecture-independent APIs. As > @Peter Dufault pointed to me in my draft the POSIX compliant way of doing it > would be through mmap, I would request your feedback on the details of the > high-level implementation of thread-stack protection. > My idea is to obtain the stack attributes of the thread that is to be mapped > by pthread_attr_getstack() and then get a file descriptor of the memory using > posix_typed_mem_open() and finally mmap that to the stack of the required > thread(With the specified permissions). > Is this is a valid approach? If yes, I believe I would have to add the > implementation of posix_typed_mem_open() to my work plan as RTEMS does > not support it as of now. > That's an interesting proposition. I guess you are suggesting to make thread stacks be "typed memory objects"? I don't know the ramifications of that, but it sounds like a really deep design and implementation challenge. It's not clear to me that "typed_mem_open" is proper to call on an existing typed object, but I'm not that familiar with the TYM interface. It could be something worth fleshing out though as a summer implementation project if there is plenty of work to do. It could be something for extension activities. I think however you could instead use shared memory objects, which already have some (limited) support, to accomplish the same ideas. You could give each thread's stack a "named" object in some filesystem, and other threads could shm_open() and mmap() the stack. I think that is the right way to go at least based on where we are in RTEMS now. You should also know and understand that the mmap() interface in RTEMS is quite shallow and restricted in its support. For file objects it basically only works to provide a copy of the file, because it works by copying the memory from the file to the destination. For shared memory objects it can provide rw access between two threads, but can't restrict access since we lack general protection mechanisms. If two threads want to share writeable stack regions then the current support could work, perhaps by using shared memory objects to set up the thread stacks. But two threads can't share read-only stack regions with the current implementation. That would be part of your work to figure out, in addition to perhaps improving and fixing up the existing mmap/shm support. Step back a minute and think about the requirements before you. Threads have stacks already. Sometimes they share them with each other. Now you want to isolate each thread's stack from other threads. But if they still want to share, then you should allow it. How? The suggestion is to allow threads to use mmap() to map other threads' stacks. Some questions for you to ponder: Since those stacks exist and have an address already, can you just fiddle with the protection regions and return a pointer directly to the stack to allow r/w access with sharing? What are the limitations on the solution (based on the number of protection regions supported in hardware)? Gedare > Regards, > Utkarsh Rai. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
