Fatal exceptions on context-switching for more than two isolated threads

[Sebastian Huber]

On 20/11/2020 00:49, Joel Sherrill wrote:

> On Thu, Nov 19, 2020, 5:00 PM Utkarsh Rai <utkarsh.rai60 at gmail.com 
> <mailto:utkarsh.rai60 at gmail.com>> wrote:
>
>
>
>     On Thu, Nov 19, 2020 at 11:39 PM Gedare Bloom <gedare at rtems.org
>     <mailto:gedare at rtems.org>> wrote:
>
>         Hi Utkarsh,
>
>         On Thu, Nov 19, 2020 at 4:59 AM Sebastian Huber
>         <sebastian.huber at embedded-brains.de
>         <mailto:sebastian.huber at embedded-brains.de>> wrote:
>         >
>         > On 19/11/2020 11:47, Utkarsh Rai wrote:
>         >
>         > >     There are a couple of other areas in RTEMS in which
>         the stack of
>         > >     another
>         > >     thread may be accessed (events, message queues,
>         signals). How did you
>         > >     solve this?
>         > >
>         > >
>         > > When we enable the thread stack protection, all the
>         services in which
>         > > a different stack is accessed becomes invalid ( This will
>         have to be
>         > > documented  ).
>         > > The user has to share the stack of the threads that will
>         be using
>         > > services like message queue with each other from the
>         application using
>         > > mmap(),shm_open(), etc. (This was a part of the work I did
>         during GSoC).
>         >
>         > This is a bit too restrictive from my point of view.
>         Consider for
>         > example this very common use of rtems_event_receive():
>         >
>         > rtems_event_set events;
>         >
>         > rtems_event_receive(..., &events, ...);
>         >
>         Let's try to keep the technical discussion on the mailing list. 
>
>
>     Oh sorry, I somehow forgot to cc the mailing list.
>
>         I
>         agree with Sebastian's point here, which is well taken. Maybe
>         it would
>         be good for you to determine the set of tests and from that the
>         features that break with strict task isolation. This way, we can
>         determine whether each is better handled as imposing a
>         requirement on
>         the user, e.g., to mmap/share explicitly in case they want to pass
>         data (such as with an mq), or if RTEMS needs to make it work
>         implicitly such as with event sets and maybe these iterators.
>
>
> I believe that sending a message that unblocks a thread will have to 
> disable the protection.
>
> The approach of identifying the few places in RTEMS that can 
> legitimately be expected to copy from one thread to another thread 
> stack can be identified and protection disabled for those segments of 
> code. This would at least properly annotate the known cases via 
> communication and synchronization and you could come back later and 
> possibly tighten those restrictions.
About eight years ago I added a stack protection to a Nios2 BSP using 
the MPU. A single MPU region was used for the thread stack. This region 
changed during a context switch. It was quite a hack and not good enough 
for general use, but worked quite well for the specific application. I 
rebased the patch to the master branch (this was surprisingly easy to do 
despite eight years of development and the addition of the SMP support). 
It gives an indication in which areas the stack of another thread is 
accessed in standard RTEMS service calls.

-- 
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-nios2-MPU-support-for-copy-routines.patch
Type: text/x-patch
Size: 4294 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201120/3791154d/attachment-0001.bin>