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 <[email protected]> wrote: >>> jblackarty wrote: >>>> An: Ivan Delamer <[email protected]>, Mailing list for lwIP users >>>> <[email protected]> >>>> 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 >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/lwip-users >> >> _______________________________________________ >> lwip-users mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> > > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users > _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
