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

[Utkarsh Rai]

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.
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200327/555ac365/attachment.html>