<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 8:34 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">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">On Thu, Aug 6, 2020 at 6:21 AM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> On 06/08/2020 14:12, Utkarsh Rai wrote:<br>
><br>
> > Hello,<br>
> > The thread-stack protection needs to be configured by the user. Two of<br>
> > the options that need configuring during build time are -<br>
> > > Enabling thread stack protection ( THREAD_STACK_PROTECTION )- This<br>
> > is a high-level option similar to RTEMS_SMP, RTEMS_POSIX_API  etc.<br>
> > > Size of the MMU pages - This is a BSP specific option.<br>
> >  Using the new build system we can configure these by adding BSP<br>
> > option ( for eg. realview BSP has 'optmmusmallpages.yml'  for 4K mmu<br>
> > pages). Similarly, we can have 'optthreadstackprotection.yml' similar<br>
> > to 'optsmp.yml' for enabling thread stack protection.  Is there<br>
> > something else we need to do, for specifying these options?<br>
> ><br>
> > Another option that needs to be specified is the number of thread<br>
> > stacks that can be shared with a particular thread. This can be done<br>
> > by specifying this in rtems/confdefs.h and then configured by the<br>
> > application. I would request your opinion on this and whether this is<br>
> > the right manner to proceed.<br>
><br>
> Yes, we probably need a new CPU option RTEMS_THREAD_STACK_PROTECTION or<br>
> similar.<br>
><br>
+1<br>
Just copy one of the existing high-level switches and give it a try,<br>
see how it turns out.<br></blockquote><div><br></div><div><div><br></div><div>Ok, I am rebasing my repo to integrate the new build system and will send the v3 patch with these switches.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Why can't you use this option in the BSP to enable the 4KiB pages MMU?<br>
><br>
Agreed. This one can be solved with documentation specific to the<br>
BSP/CPU related to how to configure it for stack protection.<br>
<br>
> With respect to the application configuration, we should consider to use<br>
> thread-local storage for this. TLS is well supported on ARM, SPARC,<br>
> PowerPC, RISC-V, and m68k.<br>
><br>
I'm not sure if I follow this thought all the way.<br>
<br>
Would the idea be to have the application populate some data structure<br>
with the pointers/names of stacks it needs to access in the TLS? And<br>
then maybe we have something that converts that structure into an<br>
internal representation, something that is kind of like a page table.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Do we have a documented way of using TLS?<br></blockquote><div><br></div><div>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.</div><div>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?</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">
<br>
Gedare<br>
</blockquote></div></div>