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

[Richard Barry]

Some replies to FreeRTOS-MPU topics, rather than lwIP topics.  A little
off topic for this mailing list I think, and not the point of the
original posters comments, but as it is being discussed I think it is ok
to give some answers:

>"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?

The kernel has extremely strict separation between what is accessible by
every task.  By default a non-privileged task can only access its own
stack, and nothing else.  API functions exist to allocate additional
memory to tasks on a task by task basis - meaning the application writer
can (for example) share RAM between tasks, or make a section of RAM
write only to one task and read only to another, etc.

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.

[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.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.



On 30/08/2012 09:23, Krzysztof Weso³owski wrote:
> 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,
> 
> On Thu, Aug 30, 2012 at 9:51 AM, Simon Goldschmidt <address@hidden> wrote:
>> jblackarty wrote:
>>> An: Ivan Delamer <address@hidden>, Mailing list for lwIP users 
>>> <address@hidden>
>>> Betreff: Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)
>>
>>>> Question: is it important for your application thread and the tcpip
>>> thread
>>>> to be in different protected memory regions? is it possible for that
>>>> memory to be accessed by both threads?
>>>
>>> As I said already, I did it so. I've placed application thread stack
>>> in separate memory region and added this region to user
>>> memory regions of tcpip thread with read/write access. Thanks to this,
>>> I was able to run my tcpip-enabled application.
>>>
>>> Is it important to avoid this in my application ?
>>> [..]
>>
>> To me, the essence of what you wrote is that the system doesn't run stable. 
>> That's of course a problem, but it wouldn't run stable with protected 
>> threads, either. 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!
>>
>>> Please, note that I didn't even talk about such
>>> details like that there are chaos is going in whole global
>>> memory shared between tasks, and network-enabled part of my
>>> application is not adequate anymore.
>>
>> What kind of chaos in global shared memory are you talking about?
>>
>>> [..]
>>> Nothing can crash kernel, provided that tasks are
>>> run in user-mode and each task has no access to other tasks threads.
>>> LwIP thread is the only thread which violates this...
>>
>> "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?
>>
>> As a summary, lwIP's multithreading design should certainly be improved if 
>> used in situations like that. 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.
>>
>> 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.
>>
>>
>> Simon
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>