Home > On-Demand Archives > Q&A Sessions >

Live Q&A - Demystifying Memory Protection Units (MPUs)

Jean Labrosse - Watch Now - EOC 2021 - Duration: 27:18

Live Q&A with Jean Labrosse for the talk titled Demystifying Memory Protection Units (MPUs)
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

CarlesMarsal
Score: 0 | 3 years ago | 1 reply

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.

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

mgaron
Score: 0 | 3 years ago | 1 reply

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.

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

CarlesMarsal
Score: 0 | 3 years ago | 1 reply

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.

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

Thank you for your kind words. I?m glad you enjoyed it.

burak.seker
Score: 1 | 3 years ago | 1 reply

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

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

DS
Score: 0 | 3 years ago | 1 reply

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?

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

DaveN
Score: 0 | 3 years ago | 1 reply

What about 3rd party libraries that use malloc/free? For example newlib, ST's drivers, etc?

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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.

Cleo
Score: 0 | 3 years ago | 1 reply

So if a device is not in a task's process table, then it cannot access it?

JeanLabrosseSpeaker
Score: 0 | 3 years ago | no reply

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!

OUR SPONSORS

OUR PARTNERS