Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)

[Simon Goldschmidt]

Richard Barry wrote:
> Some replies to FreeRTOS-MPU topics, rather than lwIP topics.  A little
> off topic for this mailing list I think

It is off topic, but nevertheless interesting (to me).

> [..]
> The kernel is privileged, so can access the task stacks, it has to store
> the task contexts and that is done on the task's stack.  The privileged
> kernel does not use the task stack for its own variables/return
> addresses/etc. though - it uses its own stack as would be expected - so
> having complete junk on the task stack would only cause a crash while
> the system was in an un-privileged mode (assuming the application
> designer has the task running un-privileged) - which would be caught by
> the MPU and not crash the kernel.
> 
> FreeRTOS-MPU does not test input parameters (it is designed to be small)
> in the same way that SafeRTOS does (SafeRTOS, which originated from
> FreeRTOS, is re-engineered to have safety as a primary goal rather than
> size - http://www.SafeRTOS.com).  User code can test before the
> parameter is passed if necessary though.

Consider this example (be warned: I don't know FreeRTOS too much):
A pointer to a semaphore is stored on the task stack, which gets corrupted. 
This pointer is then passed to a kernel function, which changes the semaphore's 
counter. Now if the pointer accidentally pointed to kernel variables, the 
kernel could get corrupted, right?

I think this *is* related to the OP's problem, as he stated that his system 
crashed because the lwIP thread has access to other task's stacks.

> [from a different email]
> > So for example, you should have tcpip_thread, communication_thread
> > and app_thread, with safe (queues?) communication comm<->app.
> 
> With regards to queues:  FreeRTOS-MPU switches to privileged mode when
> the queue API function is called to have the (more) trusted kernel code
> copy the data out of the protected memory space into a memory space that
> is only accessible to the kernel.  The same happens in reverse when the
> data is received by another task.

Sadly, this would only copy pointers, not pbuf or even payload contents (which 
are hidden behind the pbuf pointer).


Simon