Home > On-Demand Archives > Q&A Sessions >
Live Q&A - Demystifying Memory Protection Units (MPUs)
Jean Labrosse - Watch Now - Duration: 27:18
From the live chat:
Jean mentioned that not using MPU can make it difficult to certify your product. I wanted to ask if he could ellaborate on that please. Great presentation btw!
The MPU allows you to place ?access restrictions? on code and, especially the data that code can access. So, if you get either open source software and/or commercial software that you are unsure about, the MPU will prevent that ?unknown? code from accessing memory and/or I/Os you don?t want that code to access. So, if YOUR code is designed for ?safety critical? applications (avionics, medical, industrial, nuclear, etc.) that cannot afford a crash from potentially ?unsafe? code then the MPU will protect that safety critical code from the ?unsafe code?. Also, it?s extremely expensive to certify code such as TCP/IP stacks because those are huge and complex. Isolating that code with an MPU allows you to have a safety certified product using a TCP/IP that that has not been certified. Without an MPU, you simply cannot prevent unsafe code from taking a system down.
From the live chat:
It was a great presentation. Lots of fascinating information. I?m a little unclear on how you determine which tasks get grouped into processes - is it functional or a matter of which regions of processor registers they need to access? Also, I imagine the MPU and privileged mode switches adds overhead. Is it at all significant?
I would delineate processes by functionality and determine how many tasks are needed for each of those processes. So, communications could be one process with multiple tasks, controls another process, reading and writing from/to I/Os could be another process, user interface yet another, etc.
Indeed, running tasks within processes in user mode (non-privileged) does add overhead every time you make an RTOS API call! The amount of overhead depends on the API called. You might be looking at between 50 to a couple of hundred CPU cycles. The complex APIs such as OSTaskCreate() (e.g. uC/OS-III) would add a couple of hundred cycles but, that?s API does a lot of work and, in the grand scheme of thing, the overhead is irrelevant because you create tasks at startup and not run-time (at least you should).
From the live chat:
From javi : In the process table example you saw us there were many unused regions, is there any reason for that?
Well, it turns out that I only needed 3 regions for those: code, RAM and stack. However, you?d need additional regions for shared RAM and I/Os. On the ARMv7M you only have 8 total regions to play with so you have to plan how your memory is layer out.
From the live chat:
How I can document a RTOS project (a tool) that show the relation between task, priorities, sempahores and mutexes?
Like I mentioned during the Q&A, I like to do a drawing showing all the tasks and ISRs and the communication paths using queues, semaphores, mutexes, etc. Examples of those types of drawings are available from my books which can be downloaded fo free from:
https://www.weston-embedded.com/micrium-books
From the live chat:
I have a task that handle the UART messages logger. I create a queue (Object) that all the other task use for send message to the UART logger. The problem is that the object of the QUEUE that store the message consume much memory, because for example save 256 bytes to the message. If I defined a queue of the 200 elements... the queue use 51.2KB from RAM... What you suggest me to reduce this high consumption?
It sounds like the messages are not being consumed by the target on the other side of the UART (i.e. the recipient). I assume you don?t have Non-volatile memory like a EEPROM to store those messages until they can be consumed? Alternatively, instead of using fixed size messages, have you consider using a large circular buffer that would then hold variable sized messages. As long as there is a way to know either the beginning or even the end of the message then you would reduce your storage need. So, if your messages are ASCII based, NUL terminated messages would be used to know the end of the message. If you don?t use ASCII, you could use a unique 32-bit code to delineate messages.
From the live chat:
You say "Code can execute out of RAM... Susceptible to code injection attacks" Could you explain me this point?
If you set the XN bit for a region that puts a fence around RAM then code that is injected into RAM from a buffer overflow attack or other means will generate an MPU fault preventing that code from executing. Without the MPU, this would go undetected.
Hi,
About the MPU vs "malloc"/new/C++/heap thing vs memory protection (design trade-off?), couldn't it be possible to overload new/delete or provide a "process storage allocator" that would work with a "process protected storage heap". The concept will be similar to the "thread storage" pattern (POSA2, i.e. errno in posix, impure_ptr in newlib and the likes..), so a malloc operation could SVC a syscall requesting memory that would actually use the TCB (Task Control Block) to make the allocator work on the process protected heap, so to allocate a piece of that region.
Anyhow, the main issue would probably still be memory fragmentation (no MMU), unless you are using it only to allocate memory on initialization and never free it, for example to make platform code that can be composed dynamically, to improve (reduce the effort) of its composability.
Unless I didn?t understand your question, there are just not enough MPU regions (fences) that you can use with malloc() and free(). Also, you?d need to ensure proper alignment as well as power of 2 allocation size. I?d rather have a local heap for a process that is managed by the process itself or, have a heap in shared RAM managed by ?system? functions. That being said, I?d prefer fixed-size memory blocks than arbitrary size allocation blocks.
I used an MPU once and this lecture kicked me in making it an habit. Thank you for getting out of retirement for this interesting lecture. Also glad I could meet you in person in ESC Boston roughly 10 years ago.
Warm thanks from Qc.
Awesome. Great to know you enjoyed the class. As you noted, it?s a great device to use, especially since it?s included with most Cortex-M. as I indicated at the beginning of the Q&A, you DON?T have to force your code to run in user mode. If you have the discipline of not tampering with the MPU from your application, you still get a lot of benefits from using the MPU, except with less protection and less overhead.
Hats off Mr. Labrosse.
You just fit a master class on RTOS, their entities, and their protocols, all the while giving away most useful insights, tips and pitfalls in a super-divulgative and well-explained talk. It really shows this is a very known territory to you. I will definitely look at the "more reading" part of the end of the presentation.
Thank you for your kind words. I?m glad you enjoyed it.
Thanks for the effort and this good presentation. The topic is really interesting and make me wanna use MPU in my projects.
If I understand correctly, uCoSIII will be able to provide an MPU module in future releases. When do you think it will be available?
Also beyond the borders of this great presentation, I wonder that is there any plans to offer multicore (SMP or AMP) support with uCoS? I am wondering because I can only use one of the cores with CortexA9 chip and the other core is just waiting idle.
Regards
Well, I'm not sure whether it will be uC/OS-III or the Weston Embedded Solutions (WES) version which is called CesiumOS3. Weston Embedded is formed of ex-Micrium guys and they created a derived product from the Micrium software. That's because Silicon Labs released the uC/ product as open source but many 'customers/users' prefer having a commercial version of the Micrium products. The initial version of CesiumOS is identical to the uC/ products when Silicon Labs released the product for open source. From now on, CesiumOS will be maintained for commercial users. WES also maintains the uC/ products, though.
I know that WES has an AMP version of uC/OS-III. SMP is a different animal. Check with WES: www.Weston-Embedded.com for any updates.
Excellent presentation. Thank you.
I had a question about the exception that can be fired when the stack overflows. Which stack does the exception use since the task's stack just overflowed - is it the RTOS's stack?
All exceptions (on the ARM Cortex-M) forces the CPU to switch to an 'exception' (or ISR) stack. So, it's not technically the RTOS stack but the CPU's ISR/exception stack.
What about 3rd party libraries that use malloc/free? For example newlib, ST's drivers, etc?
You 'could' use an MPU region to 'wrap' all of the Heap space and add that region to all process tables. You won't be able to distinguish each of the allocated areas and protect them from one another.
So if a device is not in a task's process table, then it cannot access it?
That's correct. This is done to ensure that a task that has no business accessing an I/O device doesn't. For example, a TCP/IP stack should be allowed to access the Ethernet controller but not a User Interface process. However, if you need to access the I/Os then you simply add a region for the MPU to access those I/Os.
19:01:35 From Leandro Pérez : Great talk Jean Labrosse... I have three questions: 1) You say "Code can execute out of RAM... Susceptible to code injection attacks" Could you explain me this point? 2) I have a task that handle the UART messages logger. I create a queue (Object) that all the other task use for send message to the UART logger. The problem is that the object of the QUEUE that store the message consume much memory, because for example save 256 bytes to the message. If I defined a queue of the 200 elements... the queue use 51.2KB from RAM... What you suggest me to reduce this high consumption? 3) How I can document a RTOS project (a tool) that show the relation between task, priorities, sempahores and mutexes? 19:02:44 From Steve Schwartz-Fenwick : Hello, great talk. What recommendations do you have for using the MPU with C++? Is there any benefit we can get from the MPU given that we need the heap for C++? 19:03:19 From Jay : After your presentation, I checked on our codebase to see if we implemented the MPU, but found that MPU support is spotty for our RTOS with SMP architecture. Is this common? What is the reason? 19:03:34 From Gary to Stephane Boucher(Direct Message) : When are the 2020 talks being pulled off the site? 19:03:53 From Charles Miller : All--a round of applause for Jacob and Stephane. A superb conference, guys! Thanks to all the speakers as well. 19:04:48 From javi : In the process table example you saw us there were many unused regions, is there any reason for that? 19:05:12 From Steve Wheeler : It was a great presentation. Lots of fascinating information. I’m a little unclear on how you determine which tasks get grouped into processes - is it functional or a matter of which regions of processor registers they need to access? Also, I imagine the MPU and privileged mode switches adds overhead. Is it at all significant? 19:05:58 From Gerhard : @javi: In the table are just the values to store in the MPU registers. 19:07:37 From javi : @Gerhard, ok.. and he puts the powermeter task stack in the last region because it is the highest priority MPU region, right? 19:07:57 From metty : In the inter-process communications/data sent by value slide, messages should be small to avoid by-copy overhead. What is the maximum message size for the messages to avoid long time for copying? 19:08:19 From metty : @Jean Labrosse 19:09:32 From Sam : Another great presentation. In the weeds, loved it! Thank you. 19:10:13 From Sam : Jacob and Stephane, THANK YOU. In my view, better than DEFCON. 19:10:32 From Stephane Boucher to Gary(Direct Message) : Thank you Sam! 19:11:20 From Gary to Stephane Boucher(Direct Message) : Stephane I think you meant to send your last message to everyone. Not just me. 19:11:22 From Jay : For more on that exploit, check out last year's presentation: https://www.embeddedonlineconference.com/session/Defending_against_Hackers_Exploit_Mitigations_and_Attacks_on_Arm_Cortex-A_Devices 19:11:40 From Gerhard : @javi: I think so, but I don’t know in which order the MCU evaluates the registers. 19:11:46 From Stephane Boucher to Gary(Direct Message) : @Gary, they will stay available at least until EOC 2022 19:12:06 From Stephane Boucher to Gary(Direct Message) : Gary, they will stay available at least until EOC 2022 19:12:12 From Jose E. : Jean mentioned that not using MPU can make it difficult to certify your product. I wanted to ask if he could ellaborate on that please. Great presentation btw! 19:12:22 From Gary to Stephane Boucher(Direct Message) : Thank you. 19:12:39 From Stephane Boucher to Gary(Direct Message) : @Charles Miller, thank you! 19:13:14 From Stephane Boucher : @Charles Miller, Thank you! 19:13:48 From javi : @Gerhard, thanks for the help. I was curious about why he put the stack in the last region 19:13:52 From Charles Miller : Would a bootloader copied from flash to ram so flash can be updated be a legal case of running from RAM? Would modifying the access "on the fly" be a mitigation? That mod might be the start of a hack...? What to do, what to do... 19:14:12 From Stephane Boucher : The 2020 (& 2021) talks will stay available at least until EOC 2022 19:14:28 From Leandro Pérez : Great Stephane 19:14:47 From Stephane Boucher : Thank you Sam! 19:15:04 From Leandro Pérez to Stephane Boucher(Direct Message) : Is my first time in EOC.... Always be online? 19:15:23 From Michael Kirkhart : The first RTOS I used was uC/OS 19:15:31 From Stephane Boucher to Leandro Pérez(Direct Message) : Probably, I'd say... 19:16:19 From Leandro Pérez to Stephane Boucher(Direct Message) : I hope in the future meet all in real world 19:16:49 From Stephane Boucher to Leandro Pérez(Direct Message) : Maybe one day, we'll organize an hybrid conference 19:17:37 From Charles Miller : I like Enterprise Architect for documentation. A good UML tool. 19:19:23 From Leandro Pérez to Stephane Boucher(Direct Message) : Thanks @Jean 19:19:36 From Leandro Pérez to Stephane Boucher(Direct Message) : I like document all 19:19:50 From Leandro Pérez to Stephane Boucher(Direct Message) : Thanks 19:21:15 From Leandro Pérez : Thanks @Jean I like document all Thanks 19:22:49 From Dave Nadler : MPUs haven't been available all that long.... 19:23:40 From Jay : My impression was that it was related to SMP 19:24:03 From afwaanquadri : Thanks Jean! 19:24:59 From Rocco Brandi : one commercial RTOS that uses MPU extensively is Integrity from Green Hills https://ghs.com/products/rtos/integrity.html 19:25:16 From javi : Great, thanks Jean 19:27:42 From Steve Wheeler : Thank you. That answers my question. 19:29:50 From Stefan Petersen : You talk about processes consists of several task. Can you elaborate on your definition on processes and task? 19:29:57 From metty : Thanks @Jean Labrosse, @Beningo 19:30:24 From Bob Dowling : Thanks, Stephane & Jacob! 19:30:37 From Steve Wheeler : Jacob, will recordings of the Q&A sessions be available? 19:30:51 From afwaanquadri : Thanks Jacob and Stephane. 19:30:54 From Nikola Jovanovic : great job guys, thank you! 19:30:56 From Konstantin : Thanks, great job! 19:31:46 From Gary : HUGE thanks to Jacob and Stephane. You have both done a tremendous job. I hope to be back next year 19:32:06 From Stephane Boucher : Yes, all Q&A have been uploaded and are now available 'on-demand', other than this one that you are in right now! 19:32:26 From Stefan Petersen : Thanks! Very nice talk and explanation! 19:32:40 From afwaanquadri : I will be looking forward to next year's conference. 19:32:46 From Rob Meades : Thank you Jean, I was actually implementing MPU support on a new processor today and pondering how far I should look into proper RTOS support; you have answered EVERYTHING! 19:32:49 From metty : Thanks, Stephane & Jacob! 19:32:53 From javi : Does the MPU influence ianyhow in the debugging? 19:33:08 From David Kanceruk : Thanks Jean, Jacob and Stephane. Great conclusion to a very informative conference. 19:34:07 From Keith J : Thanks for doing this Stephane and Jacob. Love the accessibility of the online conference format... miss the personal interaction with attendees though. But nothing you can do there. 19:35:04 From Will Hsiung : Thanks Jean for the presentation and to Jacob and Stephane for the online conference! 19:35:18 From Stephane Boucher : I recognize many names here that showed up to many of the Q&A sessions. Thank you to you guys, you made that conference very interesting and vibrant! 19:35:41 From javi : Thanks, great answer 19:35:55 From Keith J : Thanks for taking the time Jean!!! 19:36:04 From Erwin : Thanks to all speakers and the organizers! You did a great job! So much useful information. Like a perfectly designed embedded System. 19:36:14 From Sam : thank you. 19:36:47 From Raul Pando : Thanks a lot, I thoroughly enjoyed the conference. Can't wait until next year :) 19:36:58 From Leandro Pérez : Thanks @Jacob, @Stephane and all the conferences.... Was a superb event!!! I will be in the event on 2022 19:37:03 From Rob Meades : Thank you Jacob and Stephane! 19:37:08 From Gerhard : Thanks! 19:37:10 From dayolawa : Thank you! 19:37:12 From Bruce Lueckenhoff : Thanks to Jacob, Stephane, and all the speakers! 19:37:32 From Steve Wheeler : I’ve really enjoyed the conference. And it’s inexpensive enough that I can afford it now that I’m retired :-) Looking forward to next year! 19:37:44 From javi : thanks, this conference has exceeded my expectations. Great job 19:38:23 From javi : Where do we go now for the beers? 19:38:48 From Dave Nadler : JJacob, do you have a beer Zoom? 19:38:52 From Yuriy Kozhynov : Many-many thanks!!! 19:38:56 From Rostifer : Thanks to all the presenters and organizers! 19:38:59 From Sam : This was my first EOC. Better than DEFCON that I attended. More in depth. 19:39:19 From Leandro Pérez : lol 19:39:54 From Leandro Pérez : Regards from Latam… It was a great resource 19:39:56 From Jay : thanks!! 19:39:58 From Rocco Brandi : thanks! 19:39:58 From Keith J : To a better 2021 all 19:40:01 From Jose E. : thanks!
From the live chat:
I was curious about why he put the stack in the last region.
The higher the region the higher the priority. This ensure that stack overflows will be detected even if other regions permit access to the RAM space. In fact, if anything, there?s a greater likelihood to have a stack overflow than most other memory violations.