Automatic wiping of task's stack

Kernel
1

Hi !

I can see task’s stack might keep sensitive data in stack.
Have it sense and automatically wipe unused part of it at the moment of task switch ?
If RTOS is tickless , not so much overhead for switch time at all.
Code is quite simple.
Regards, Eugene

#define taskCHECK_FOR_STACK_OVERFLOW()																\
{	\
	const uint32_t * const pulStack = ( uint32_t * ) pxCurrentTCB->pxStack; \
	const uint32_t ulCheckValue = ( uint32_t ) 0xa5a5a5a5;									\
																									                  \
	if( ( pulStack[ 0 ] != ulCheckValue ) ||												  \
		( pulStack[ 1 ] != ulCheckValue ) ||														\
		( pulStack[ 2 ] != ulCheckValue ) ||														\
		( pulStack[ 3 ] != ulCheckValue ) )															\
	{	\
		vApplicationStackOverflowHook( ( TaskHandle_t ) pxCurrentTCB, pxCurrentTCB->pcTaskName );	\
	}	else { \
	  \
	  /* Wipe task's stack */ \
	  const uint32_t * const topStack = ( uint32_t * ) pxCurrentTCB->pxTopOfStack; \
             for ( volatile uint32_t * ptr = (uint32_t *)pulStack; ptr < (uint32_t *)topStack; ptr++ ) { \
    ptr[0] = ulCheckValue; } \
  \
	} \
}
2

There could be data stored at any place in the stack. We could wipe the unused part of the stack, but that is all, and that would take a relatively long time on context switched. If you have this need I would suggest using a memory protected port instead. By default a memory protected task can only see its own stack, and nothing else. The application writer then has to explicitly give access to any other memory. https://www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html

3

yes, I’m using LPC55x with MPU and TZ enablers and afraid temporary buffers in any case.

4

I will make a general comment about this general idea that you have made both here and some other threads. Anyone who could have read the data in the leftover stack could also have read it while the data was active, so this activity is really just slightly reducing the risk surface. If you are REALLY concerned about this sort of exposure then the task itself should have zeroed the buffer when it was done, rather than waiting for the stack to free it and then a task switch to occur. That would minimize the surface better, and also minimize the cost (automatically clearing the stack could add significant costs to operations).

On ‘Big’ machines, generally, you don’t worry about ‘secrets’ in your local address space, as that is considered fairly secure, but do need to watch out for memory being swapped or returned to the system.

FreeRTOS on the other hand mostly uses a ‘Small’ machine model, where all parts of the system are considered ‘1 program’, so there isn’t as secure of isolation between sections, so you need to think about security differently. There shouldn’t be any ‘untrusted’ code running anywhere near your secure code. WIth an MPU, you could relegate all the untrusted code to being in restricted tasks, (and even then you need to have some trust in that code).

In some ways, the sort of ad-hoc clearing REDUCES the security of the system if you put any reliance on it, as it is always later than it could have been.

5

Yes, whole chain looks like this:

  • crypto library cleaning some own internal buffers
  • external big buffers are cleaned explicitly
  • rtos should clean stack rtos internal buffers
  • malloc/free clean buffers at allocation/free point.
    It just coding techniques for be sure if everything is cleaned.