Memory protection was Re: change log for rtems (2011-10-21)

Joel Sherrill joel.sherrill at OARcorp.com
Tue Oct 25 20:18:11 UTC 2011


On 10/24/2011 08:55 AM, Sebastian Huber wrote:
> We are (at the moment) not interested in a general MPU or MMU API.  Currently
> we use a Nios II specific API to do the low level stuff.
Eventually this would result in 15+ APIs in RTEMS.  After suffering
through a few IRQ APIs that were related but different, I would
expect you to feel a cold chill and shudder about now.
>   We are interested in
> thread stack protection.  This means that stack overflows are detected and
> access to other thread stacks is prohibited.

Stack overflow detection is OK.

Stack protection is likely to result in a violation of the POSIX
process/thread model.  RTEMS is best compared to a thread
implementation in a user space library in POSIX process terms.
> The basic problem with stack
> protection is in the following pattern (within the Score):
>
> *(type *)the_thread->Wait.return_argument = value_of_type;
>
> _CORE_message_queue_Copy_buffer(
>         buffer,
>         waitp->return_argument_second.mutable_object,
>         size
> );
>
> Here a thread B can send data to a thread A.  Normally the storage for received
> events or messages reside on the thread stack.  Thus we copy here data within
> the context of thread B into the thread stack of thread A.  This is not allowed
> in general.  We may allow it in certain situations (like in the Score).  For
> example in the situations above it is save to copy the data (we only protect
> the thread stacks) since thread A already checked the access to it implicitly.
>    (The kernel access functions are not leaf functions, thus we have to store
> the link register on the stack.)
>
This is just one of hundreds of situations.  The contents of a message
or global data structure could point to a variable on a stack.  It is
completely OK in POSIX and would break under what you are describing
limiting.

Rather than hack RTEMS, it would be better to have programming rules
that no pointers to stack data is put into global areas and no stack
memory is used for message buffers. There are likely more.  But it
wouldn't be that many I think.

If we add the next tier of MMU support, you end up with something
like RTP in a closed source RTOS or real processes ala POSIX.  Better
to invest the effort for the bigger goal.  And for now, have programming
rules that eliminate the sharing of stack data across threads.

You restricting your programming techniques does not violate POSIX.

--joel
> On 10/24/2011 03:17 PM, Gedare Bloom wrote:
>> If you have some api for memory protection I would like to know and be happy to
>> review it. I have been looking at the gsocmmu code to see about getting it
>> mergeable.
>>
>> On Oct 23, 2011 4:22 AM, "Sebastian Huber"<sebastian.huber at embedded-brains.de
>> <mailto:sebastian.huber at embedded-brains.de>>  wrote:
>>
>>      On 22/10/11 19:23, Chris Johns wrote:
>>
>>          On 21/10/11 8:11 PM, rtems-vc at rtems.org<mailto:rtems-vc at rtems.org>  wrote:
>>
>>              +#else /* ASM */
>>              +
>>              +    .macro    NIOS2_ASM_DISABLE_INTERRUPTS new_status, current_status
>>              +    movhi    \new_status, %hiadj(_Nios2_ISR_Status_mask)
>>              +    addi    \new_status, \new_status, %lo(_Nios2_ISR_Status_mask)
>>              +    and    \new_status, \current_status, \new_status
>>              +    ori    \new_status, \new_status, %lo(_Nios2_ISR_Status_bits)
>>              +    wrctl    status, \new_status
>>              +    .endm
>>              +
>>              +#endif /* ASM */
>>
>>
>>          What is this for and do we use it ?
>>
>>
>>      It can be used to disable interrupts in assembler code.  It is used by our
>>      not yet committed BSP which has support for the memory protection unit
>>      (MPU) to protect the thread stacks.  It will take several weeks until this
>>      is ready for integration into the CVS.  We need a couple of changes in the
>>      Score.
>>
>>      --
>>      Sebastian Huber, embedded brains GmbH
>>
>>      Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>>      Phone   : +49 89 18 90 80 79-6<tel:%2B49%2089%2018%2090%2080%2079-6>
>>      Fax     : +49 89 18 90 80 79-9<tel:%2B49%2089%2018%2090%2080%2079-9>
>>      E-Mail  : sebastian.huber at embedded-__brains.de
>>      <mailto:sebastian.huber at embedded-brains.de>
>>      PGP     : Public key available on request.
>>
>>      Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>>      _________________________________________________
>>      rtems-vc mailing list
>>      rtems-vc at rtems.org<mailto:rtems-vc at rtems.org>
>>      http://www.rtems.org/mailman/__listinfo/rtems-vc
>>      <http://www.rtems.org/mailman/listinfo/rtems-vc>
>>
>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985





More information about the vc mailing list