[RTEMS Project] #4955: sparc: Potential stack corruption in uniprocessor configurations during start multitasking

RTEMS trac trac at rtems.org
Thu Oct 12 11:53:39 UTC 2023


#4955: sparc: Potential stack corruption in uniprocessor configurations during
start multitasking
-----------------------------+------------------------------
 Reporter:  Sebastian Huber  |       Owner:  Sebastian Huber
     Type:  defect           |      Status:  closed
 Priority:  normal           |   Milestone:  6.1
Component:  arch/sparc       |     Version:  6
 Severity:  critical         |  Resolution:  fixed
 Keywords:  qualification    |  Blocked By:
 Blocking:                   |
-----------------------------+------------------------------
Changes (by Sebastian Huber <sebastian.huber@…>):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"1c36971d9245fe0c212890d61cb43a8d7fa14e1c/rtems"
 1c36971d/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="1c36971d9245fe0c212890d61cb43a8d7fa14e1c"
 sparc: Fix stack corruption

 Fix a potential stack corruption in uniprocessor configurations during
 start multitasking.

 The system initialization uses the interrupt stack.  A first level
 interrupt shall never interrupt a context which uses the interrupt
 stack.  Such a use would lead to stack corruption and undefined system
 behaviour.  Unfortunately, in uniprocessor configurations this was the
 case.  Multiprocessing is started using _CPU_Context_restore().  The
 caller of this function (_Thread_Start_multitasking()) uses the
 interrupt stack.  Later we have in cpukit/score/cpu/sparc/cpu_asm.S:

         mov     %g1, %psr                     ! restore status register
 and
                                               ! **** ENABLE TRAPS ****

         ld      [%o1 + G5_OFFSET], %g5        ! restore the global
 registers
         ld      [%o1 + G7_OFFSET], %g7

         ! Load thread specific ISR dispatch prevention flag
         ld      [%o1 + ISR_DISPATCH_DISABLE_STACK_OFFSET], %o2
         ! Store it to memory later to use the cycles

         ldd     [%o1 + L0_OFFSET], %l0        ! restore the local
 registers
         ldd     [%o1 + L2_OFFSET], %l2
         ldd     [%o1 + L4_OFFSET], %l4
         ldd     [%o1 + L6_OFFSET], %l6

         ! Now restore thread specific ISR dispatch prevention flag
         st      %o2, [%g6 + PER_CPU_ISR_DISPATCH_DISABLE]

         ldd     [%o1 + I0_OFFSET], %i0        ! restore the input
 registers
         ldd     [%o1 + I2_OFFSET], %i2
         ldd     [%o1 + I4_OFFSET], %i4
         ldd     [%o1 + I6_FP_OFFSET], %i6

         ldd     [%o1 + O6_SP_OFFSET], %o6     ! restore the output
 registers

 Between the ENABLE TRAPS and the restore of the output registers, we
 still use the stack of the caller and interrupts may be enabled.  If an
 interrupt happens in this code block, the interrupt stack is
 concurrently used which may lead to a crash.

 Fix this by adding a new function _SPARC_Start_multiprocessing() for
 uniprocessor configurations.  This function first sets the stack pointer
 to use the stack of the heir thread.

 Close #4955.
 }}}

--
Ticket URL: <http://devel.rtems.org/ticket/4955#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list