Design issues with thread-stack isolation/sharing.

[Utkarsh Rai]

On Mon, Aug 3, 2020 at 9:35 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Sun, Aug 2, 2020 at 5:46 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
> >
> >
> >
> > On Sat, Aug 1, 2020 at 10:51 PM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Sat, Aug 1, 2020 at 10:38 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
> >> >
> >> > This thread is an attempt to consolidate and resolve all the issues
> that have been raised related to my patches- 1.
> https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2.
> https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend
> to first resolve all the issues through this thread( and probably convert
> this into a blog-post ), before making any further changes.
> >> >
> >> > 1. Stack address name that needs to be passed to shm_open() - This
> was briefly discussed here, and I believe the reason we still have issues
> with this is because of my incorrect interpretation of what was suggested.
> My idea was that we need to assign a name like "/taskfs/pid" to each stack
> address on the creation of the thread. On looking around further, I realize
> we can have the stack address name the same as the thread name.
> >> >
> >> ok. the /taskfs idea was more of a longer-term concept. I think it
> >> would require possibly an entire GSoC itself. It'd be nice though :)
> >>
> >> > 2. Switching out shared stacks- In my current implementation,
> removing protected stacks is done through assembly code but the
> '_Stackprotection_Context_switch' which switches out the shared stack is
> difficult to implement in assembly. But we need to integrate the shared
> stack switching in the context switching code as we don't have access to
> executing thread attributes anywhere else.
> >> >
> >> I think the real problem here is that your code to switch stacks is
> >> too complicated. It would certainly be folly to try to implement
> >> linked list processing in assembly of the context switch, but you
> >> shouldn't need to be walking a linked list anyway. There are simpler
> >> solutions that would work just as well, including replacing the entire
> >> address space (e.g., switching the page table base register) or using
> >> an array to store the shared stack addresses and just iterating the
> >> array.
> >
> >
> > Ok, but this would mean that we can only share a set number of stacks
> with each thread?
> >
>
> Perhaps. You might be able to use an extendable array if the number of
> shared stacks is configurable. This again goes into the problem that
> configuration hasn't been solved yet.
>

Ok, I will do this with a fixed array for now. I have started to try out
the new build system and most probably try to resolve the configuration
issue this week


>
> >>
> >>
> >> > 3. Integration of the 'Stackprotection_attr' structure with the
> thread and stack control structure - The integration is a pretty
> straightforward task, the difficulty lies in handling the attribute offset
> in the assembly code, whereas having the 'Stackprotection_attr'  just after
> the context control attribute in the thread control structure makes
> handling the offset relatively easy.
> >> >
> >> The Stack_Control is embedded already, you just need to calculate the
> >> location of Thread_Control.Start.Initial_stack first, and then offset
> >> within that structure.
> >
> >
> > I agree it's just that it is extra work and maybe I was being lazy :).
>
> Maybe. Sometimes it is better to pay now than later though.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200803/ea78a7be/attachment.html>