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

[Gedare Bloom]

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.

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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel