I have added/rectified all the valuable changes provided by the community in my proposal. In particular, I have added the implementation of TYM in my draft. It would be very kind of you if you could have a final glance at the proposal before I submit the final pdf draft.
On Sat, Mar 28, 2020 at 7:30 PM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > Got it, I will modify my proposal draft accordingly. > > On Sat, Mar 28, 2020 at 7:12 PM Gedare Bloom <ged...@rtems.org> wrote: > >> On Sat, Mar 28, 2020 at 4:59 AM Peter Dufault <dufa...@hda.com> wrote: >> > >> > >> > >> > > On Mar 27, 2020, at 14:16 , Utkarsh Rai <utkarsh.ra...@gmail.com> >> wrote: >> > > >> > > >> > > On Fri, Mar 27, 2020 at 9:31 PM Gedare Bloom <ged...@rtems.org> >> wrote: >> > > 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. >> > > >> > > I had looked into that and therefore initially proposed a separate >> 'mem_share()' interface, but as was pointed out, it was not POSIX compliant. >> > > So I guess, adding on to the existing mmap/shm support is the best >> way to move forward. >> > > >> > > 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? >> > > I guess if a thread makes explicit calls to mmap for stack sharing >> and the access to other stacks is not granted, this can be implemented(At >> the hardware level it would mean that the page table attributes would be >> updated for the thread-stack that is to be mapped). >> > > What are the limitations on the solution (based on the >> > > number of protection regions supported in hardware)? >> > > As was mentioned in a separate thread we would have to go with the >> common minimum hardware support to support maximum targets. >> > > Gedare >> > > >> > > > Regards, >> > > > Utkarsh Rai. >> > > > ______________________________________________ >> > >> > My rationale for suggesting Utkarsh examine the typed memory object >> interface, after five minutes of in-depth analysis, was that you could >> immediately get into the code specific to memory mapping stacks as the file >> descriptor would have to be one for a stack. You could use >> "posix_typed_mem_get_info()" to assert that the FD is a stack object prior >> to doing your "mmap()". >> > >> > I've just spent another five minutes. There are three functions that >> would need to be "derived" from existing functions with additional >> information associated with those typed memory file descriptors. >> > >> > • posix_mem_offset - find offset and length of a mapped typed memory >> block (ADVANCED REALTIME) >> > • posix_typed_mem_get_info - query typed memory information (ADVANCED >> REALTIME) >> > • posix_typed_mem_open - open a typed memory object (ADVANCED REALTIME) >> > >> > Maybe this is overkill. >> > >> >> For this specific use case I would try to make it work with SHM first, >> fixing up what we already have for mmap/shm support. But adding TYM is >> a noteworthy challenge that could be worked on in the same GSoC >> project. It just looks like a harder, more complicated road to follow. >> >> > Peter >> > ----------------- >> > Peter Dufault >> > HD Associates, Inc. Software and System Engineering >> > >> > This email is delivered through the public internet using protocols >> subject to interception and tampering. >> > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
