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

[Utkarsh Rai]

I have added/rectified all the valuable changes provided by the community
in my proposal. In particular, I have added the implementation of TYM in my
draft. It would be very kind of you if you could have a final glance at the
proposal before I submit the final pdf draft.

On Sat, Mar 28, 2020 at 7:30 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:

> Got it, I will modify my proposal draft accordingly.
>
> On Sat, Mar 28, 2020 at 7:12 PM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Sat, Mar 28, 2020 at 4:59 AM Peter Dufault <dufault at hda.com> wrote:
>> >
>> >
>> >
>> > > 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.
>> >
>>
>> 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.
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200330/6c0b1bbe/attachment.html>