veyepar: Sane Behaviour on Teeny Hardware

Author(s):	Seb Holzapfel
Location	Collaborative Lecture Theatre CB11.00.405
Date	jan Thu 25	Days Raw Files
Start	16:45	First Raw Start	16:38
Duration	0:45:0	Offset	0:06:06
End	17:30	Last Raw End	17:38
Chapters	00:00 0:22:05
Total cuts_time	43 min.

http://lca2018.linux.org.au/schedule/presentation/103/
raw-playlist raw-mp4-playlist encoded-files-playlist host archive public tweet mp4 svg png

assets release.pdf Sane_Behaviour_on_Teeny_Hardware.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

By necessity, embedded systems often use low power, cheap parts - which means that the device that flies your drone or keeps your heart beating is likely not to have a Memory Management Unit. This means that the usual protection provided by virtual memory against programming errors or untrustworthy code is absent - any task can access all memory.

Microcontroller designers recognised this problem and started to tack on a cheaper Memory Protection Unit instead. Memory partitions can be created by the programmer using the MPU to protect the kernel, real-time tasks and other data from each other - however using it effectively is not easy.

This talk will present how we implemented support for the MPU in ARM's Cortex-M series of microprocessors (a popular choice for low-power embedded designs) in eChronos, an open-source real-time operating system. It will explore how that support can be used to protect one task's data from another, the kernel from the payload tasks, and for other purposes - like sandboxing questionable third-party drivers. The implementation process was not straightforward - with many scrapped design prototypes, and traps for the unwary. Our experience represents an attempt to make the MPU usable without undue burden on the programmer using the system, and without compromising real-time properties. Other points in the design space will be discussed, along with our reasoning as to the implementation decisions we made.

A number of live hardware demonstrations (attempting to compromise MPU-less and MPU-protected systems) will be given throughout the talk.

Comment:

production notes