Discussion regarding high-level interface for GSoC memory protection project.

[Peter Dufault]

> On Mar 27, 2020, at 14:16 , Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
> 
> 
> On Fri, Mar 27, 2020 at 9:31 PM Gedare Bloom <gedare at 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.rai60 at 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.

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.