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

[jblackarty]

> So while I also think that protecting the thread's stacks against
> each other would be a good thing, the lack of this protection
> doesn't seem to be the cause of your problems!

This is the most interesting thing. How can can I find out cause of
crash in such complex system. I haven't professional expensive
development tools which allow me to use complex debugging methods. I'm
just double-checked my code and I'm 95% sure that lwip is the cause.

> What kind of chaos in global shared memory are you talking about?

Given the fact that lwip intensively uses pointers, chained lists,
etc, it seems like somebody (I'm sure it's lwip code) overflows some memory
space overwriting some pointer(s) due to wrong pointers/offsets
arithmetic. This launches chain reaction of
incorrect memory accesses. Since data values (which becomes pointers)
are unknown, consequences are unpredictable. Every time my application
crashes it happens in different ways: memory fault exceptions in
different spaces (both in user-space code and kernel), memp_sanity
check failures, pbuf's pool memory leaks, mysterious disappearances of
kernel objects (tasks) from debugger view, corruption of protected
critical kernel variables (e.g. pxCurrentTCB), etc.

> "Nothing can crash kernel": this would only hold for a kernel that
> is strictly seperated from tasks stacks and very strictly checks
> arguments passed from threads to kernel functions, wouldn't it? Is 
> FreeRTOS-MPU designed like that?

Almost yes. The only exception is that it cannot check system object
handle, because it's just pointer to allocated data on protected heap.

> The reason for all this is that lwIP has not been designed for MPU
> systems. It has been designed for very small systems at a time where
> MPUs were not available for systems of that size.

Yes, I understand. But I thought that lwip greatly expanded since that
and will match my design.

> However, the fact remains that global memory like pbufs is still
> shared (e.g. between ISR, tcpip_thread and application threads), so
> I don't think you would gain too much security unless protecting most pools.

> I would like to add, that in my opinion if LwIP is considered unsafe,
> all threads using it should be treated this way.
>
> So for example, you should have tcpip_thread, communication_thread and
> app_thread, with safe (queues?) communication comm<->app.
>
> Regards,
> Krzysztof Wesołowski

Yes, I know it. My aim is to form a something like "network domain", which will
include lwip, ethernet driver, network-related application threads and
associated data. Their crash must be separated from the entire system.