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

[jblackarty]

> Hi,
>
> do you mean this situation?
>
> Thread A = tcpip thread - stack protected by MPU, only A and
> privileged mode can access it
> Thread B = user thread - stack protected by MPU, only B and privileged
> mode can access it
> [...]

Yes.

> The privileged kernel does not use the task stack for its own variables/return
> addresses/etc.

Richard, I'm going to surprise you. It does! I've analyzed ARM CM3 port and
didn't found that syscall switches SPSEL to SP_main (MSP). To be
completely sure I've checked SP register values at run-time while
debugging.
But even supposing that it was handled as you said, then how do you
see this working ? Concurrent system calls from multiple threads drops
local variables of freertos api functions to single main stack in
random untracked order ? It turns out that I'm still right: corrupting
a thread stack can cause kernel crash.

>> 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?
>>
>
> If the pointer was corrupted such that it pointed outside of the RAM the
> task was permitted to access, and you dereferenced that pointer from a
> task, you would get a protection fault *before* any data was modified.
> The kernels own data is only accessible to it, so you could not corrupt
> the kernel's data in this scenario.
>
> If the pointer was corrupted in any way, and was passed into a kernel
> function, then (as per my previous email) the kernel does not check the
> pointer's value and as the kernel is privileged it could cause a
> problem.  SafeRTOS would protect against that because it checks the
> validity of what the pointer is pointing to using mirror variables,
> etc., but FreeRTOS-MPU does not.  The application can protect against
> that however by performing extra tests in its own code.  For example,
> you can have a "check_pointer()" function that is called before the
> pointer is passed to the kernel - or even wrap that up in a macro so it
> happens automatically.  The implementation of check_pointer() can then
> use guards around the pointer, or bitwise mirrors, etc.

Agree, Simon pointed to a vulnerability I was not aware of. I have no
idea how check_pointer() can be implemented to be executed from
user-mode thread context. I'll google for biwise mirrors... But I found
solution for pool-based configuration. All pointers should be placed in separate
memory region with read-only access for all threads and initialized
only at startup (in privileged non-RTOS mode).

> Given the nature of network communication, for such clean
> separation, you would have to create an API layer that does not need
> communicating threads to share memory with lwIP. The most tricky
> part here would be sharing TX/RX data between those threads: to
> prevent having a priviledged-mode handler copying the data between
> protection regions, you would have to adapt memory protection on the
> fly (i.e. or TX data, TX pbuf's contents may be written by the
> application thread and read by lwIP, for RX, lwIP may write and the 
> application may read only).
>
> However, although this seems interesting, lwIP's design is far away from this 
> (yet?).

Very very far, in my opinion. But I believe that lwip design can be
smoothly reworked to avoid stack access violation by simply placing those local
variables in global pools (at least, optionaly, to give user choice
between safety and memory usage). Plus given my solution of vulnerability you
found previously, it'll be a great improvement of crash safety.