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

[FreeRTOS Info]

To be clear, my email below related to FreeRTOS-MPU, which is a separate
port to standard FreeRTOS - the latter not using an MPU at all.

[Did other people receive my original email?  I noticed I sent it from
an email address I didn't know I had registered with this list.  In any
case, it is below if not].


On 30/08/2012 09:45, Richard Barry wrote:
> 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
>>
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>