<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 27, 2020 at 9:31 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Utkarsh,<br>
<br>
You can remove "Discussion regarding" from your subject lines. We know<br>
your emails are discussions regarding the subject.<br>
<br>
On Fri, Mar 27, 2020 at 5:26 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
> 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.<br>
> 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).<br>
>   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.<br>
><br>
<br>
That's an interesting proposition. I guess you are suggesting to make<br>
thread stacks be "typed memory objects"? I don't know the<br>
ramifications of that, but it sounds like a really deep design and<br>
implementation challenge. It's not clear to me that "typed_mem_open"<br>
is proper to call on an existing typed object, but I'm not that<br>
familiar with the TYM interface. It could be something worth fleshing<br>
out though as a summer implementation project if there is plenty of<br>
work to do. It could be something for extension activities.<br>
<br>
I think however you could instead use shared memory objects, which<br>
already have some (limited) support, to accomplish the same ideas. You<br>
could give each thread's stack a "named" object in some filesystem,<br>
and other threads could shm_open() and mmap() the stack. I think that<br>
is the right way to go at least based on where we are in RTEMS now.<br>
<br>
You should also know and understand that the mmap() interface in RTEMS<br>
is quite shallow and restricted in its support. For file objects it<br>
basically only works to provide a copy of the file, because it works<br>
by copying the memory from the file to the destination. For shared<br>
memory objects it can provide rw access between two threads, but can't<br>
restrict access since we lack general protection mechanisms. If two<br>
threads want to share writeable stack regions then the current support<br>
could work, perhaps by using shared memory objects to set up the<br>
thread stacks. But two threads can't share read-only stack regions<br>
with the current implementation. That would be part of your work to<br>
figure out, in addition to perhaps improving and fixing up the<br>
existing mmap/shm support.<br>
<br></blockquote><div>  I had looked into that and therefore initially proposed a separate 'mem_share()' interface, but as was pointed out, it was not POSIX compliant.</div><div> So I guess, adding on to the existing mmap/shm support is the best way to move forward.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Step back a minute and think about the requirements before you.<br>
Threads have stacks already. Sometimes they share them with each<br>
other. Now you want to isolate each thread's stack from other threads.<br>
But if they still want to share, then you should allow it. How?<br>
<br>
The suggestion is to allow threads to use mmap() to map other threads'<br>
stacks. Some questions for you to ponder: Since those stacks exist and<br>
have an address already, can you just fiddle with the protection<br>
regions and return a pointer directly to the stack to allow r/w access<br>
with sharing? </blockquote><div>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). </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What are the limitations on the solution (based on the<br>
number of protection regions supported in hardware)?<br></blockquote><div>As was mentioned in a separate thread we would have to go with the common minimum hardware support to support maximum targets.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Gedare<br>
<br>
> Regards,<br>
> Utkarsh Rai.<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>
</div>
</div>