Configuration option for thread-stack protection.

Utkarsh Rai utkarsh.rai60 at gmail.com
Thu Aug 6 16:49:10 UTC 2020


On Thu, Aug 6, 2020 at 8:34 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Thu, Aug 6, 2020 at 6:21 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> >
> > On 06/08/2020 14:12, Utkarsh Rai wrote:
> >
> > > Hello,
> > > The thread-stack protection needs to be configured by the user. Two of
> > > the options that need configuring during build time are -
> > > > Enabling thread stack protection ( THREAD_STACK_PROTECTION )- This
> > > is a high-level option similar to RTEMS_SMP, RTEMS_POSIX_API  etc.
> > > > Size of the MMU pages - This is a BSP specific option.
> > >  Using the new build system we can configure these by adding BSP
> > > option ( for eg. realview BSP has 'optmmusmallpages.yml'  for 4K mmu
> > > pages). Similarly, we can have 'optthreadstackprotection.yml' similar
> > > to 'optsmp.yml' for enabling thread stack protection.  Is there
> > > something else we need to do, for specifying these options?
> > >
> > > Another option that needs to be specified is the number of thread
> > > stacks that can be shared with a particular thread. This can be done
> > > by specifying this in rtems/confdefs.h and then configured by the
> > > application. I would request your opinion on this and whether this is
> > > the right manner to proceed.
> >
> > Yes, we probably need a new CPU option RTEMS_THREAD_STACK_PROTECTION or
> > similar.
> >
> +1
> Just copy one of the existing high-level switches and give it a try,
> see how it turns out.
>


Ok, I am rebasing my repo to integrate the new build system and will send
the v3 patch with these switches.


>
> > Why can't you use this option in the BSP to enable the 4KiB pages MMU?
> >
> Agreed. This one can be solved with documentation specific to the
> BSP/CPU related to how to configure it for stack protection.
>
> > With respect to the application configuration, we should consider to use
> > thread-local storage for this. TLS is well supported on ARM, SPARC,
> > PowerPC, RISC-V, and m68k.
> >
> I'm not sure if I follow this thought all the way.
>
> Would the idea be to have the application populate some data structure
> with the pointers/names of stacks it needs to access in the TLS? And
> then maybe we have something that converts that structure into an
> internal representation, something that is kind of like a page table.


> Do we have a documented way of using TLS?
>

I have the same doubt, I looked around but could not find anything that
describes a way of using TLS. We can have an array of shared stack
attributes(address, length, flags) placed in the TLS.
But how will it be different/beneficial than simply adding these attributes
to the thread-stack control block and setting/unsetting them on each
context switch?


> Gedare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200806/34dc0d6d/attachment.html>


More information about the devel mailing list