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

Reply via email to