Tock Operating System Safety without Processes for Embedded Systems - - PowerPoint PPT Presentation

▶
tock operating system
SMART_READER_LITE
LIVE PREVIEW

Tock Operating System Safety without Processes for Embedded Systems - - PowerPoint PPT Presentation

Mar 31, 2024 12 likes •582 views

Tock Operating System Safety without Processes for Embedded Systems 1 Stanford University 2 University of Michigan 3 University of California, Berkeley 1 Amit Levy 1 Brandon Ghena 2 Michael Andersen 3 Brad Campbell 2 Gabe Fierro 3 Pat Pannuto 2

slide-1
SLIDE 1

Tock Operating System

Safety without Processes for Embedded Systems

Amit Levy 1 Brandon Ghena 2 Michael Andersen 3 Brad Campbell 2 Gabe Fierro 3 Pat Pannuto 2 Prabal Dutta 2 David Culler 3 Philip Levis 1

1Stanford University 2University of Michigan 3University of California, Berkeley

1

slide-2
SLIDE 2

2

slide-3
SLIDE 3

Tock

Tock is a safe operating system for embedded systems, designed for low resource consumption:

  • 16KB-512KB memory
  • Sub-1mA average current draw
  • Order of millisecond timing constraint (O(10000 cycles))

with a central focus on isolating untrusted components achieved (primarily) by using a safe language to isolate components in the kernel

3

slide-4
SLIDE 4

Tock

Tock is a safe operating system for embedded systems, designed for low resource consumption:

  • 16KB-512KB memory
  • Sub-1mA average current draw
  • Order of millisecond timing constraint (O(10000 cycles))

with a central focus on isolating untrusted components achieved (primarily) by using a safe language to isolate components in the kernel

3

slide-5
SLIDE 5

Tock

Tock is a safe operating system for embedded systems, designed for low resource consumption:

  • 16KB-512KB memory
  • Sub-1mA average current draw
  • Order of millisecond timing constraint (O(10000 cycles))

with a central focus on isolating untrusted components achieved (primarily) by using a safe language to isolate components in the kernel

3

slide-6
SLIDE 6

Tock

Tock is a safe operating system for embedded systems, designed for low resource consumption:

  • 16KB-512KB memory
  • Sub-1mA average current draw
  • Order of millisecond timing constraint (O(10000 cycles))

with a central focus on isolating untrusted components achieved (primarily) by using a safe language to isolate components in the kernel

3

slide-7
SLIDE 7

Tock

Tock is a safe operating system for embedded systems, designed for low resource consumption:

  • 16KB-512KB memory
  • Sub-1mA average current draw
  • Order of millisecond timing constraint (O(10000 cycles))

with a central focus on isolating untrusted components achieved (primarily) by using a safe language to isolate components in the kernel

3

slide-8
SLIDE 8

Embedded ”operating systems” exist (TinyOS, FreeRTOS, Arduino, etc) But they’re not operating systems like you’re used to: No strict separation between a kernel, drivers and applications. No mechanism for isolating components from each other The ”OS” is basically a library Think Ruby on Rails for your defibrilator

4

slide-9
SLIDE 9

Embedded ”operating systems” exist (TinyOS, FreeRTOS, Arduino, etc) But they’re not operating systems like you’re used to: No strict separation between a kernel, drivers and applications. No mechanism for isolating components from each other The ”OS” is basically a library Think Ruby on Rails for your defibrilator

4

slide-10
SLIDE 10

Embedded ”operating systems” exist (TinyOS, FreeRTOS, Arduino, etc) But they’re not operating systems like you’re used to: No strict separation between a kernel, drivers and applications. No mechanism for isolating components from each other The ”OS” is basically a library Think Ruby on Rails for your defibrilator

4

slide-11
SLIDE 11

Embedded ”operating systems” exist (TinyOS, FreeRTOS, Arduino, etc) But they’re not operating systems like you’re used to: No strict separation between a kernel, drivers and applications. No mechanism for isolating components from each other The ”OS” is basically a library Think Ruby on Rails for your defibrilator

4

slide-12
SLIDE 12

Embedded ”operating systems” exist (TinyOS, FreeRTOS, Arduino, etc) But they’re not operating systems like you’re used to: No strict separation between a kernel, drivers and applications. No mechanism for isolating components from each other The ”OS” is basically a library Think Ruby on Rails for your defibrilator

4

slide-13
SLIDE 13

Embedded ”operating systems” exist (TinyOS, FreeRTOS, Arduino, etc) But they’re not operating systems like you’re used to: No strict separation between a kernel, drivers and applications. No mechanism for isolating components from each other The ”OS” is basically a library Think Ruby on Rails for your defibrilator

4

slide-14
SLIDE 14

How do we build embedded systems?

5

slide-15
SLIDE 15
  • 1. Build a platform
  • MCU
  • Radio
  • Sensors
  • Actuators

Each platform is a unique snowflake

6

slide-16
SLIDE 16
  • 1. Build a platform
  • MCU
  • Radio
  • Sensors
  • Actuators

Each platform is a unique snowflake

6

slide-17
SLIDE 17
  • 2. Choose an ”OS”
  • Arduino
  • TinyOS
  • FreeRTOS

7

slide-18
SLIDE 18
  • 3. Pull in drivers for the platform
  • Bluetooth driver from Nordic
  • 802.15.4 driver from Thingsquare
  • Temperature sensor driver from Adafruit

8

slide-19
SLIDE 19
  • 4. Build application(s) on top

9

slide-20
SLIDE 20
  • 5. Optimize for !security

Often modifications to the whole stack to get better performance and energy consumption

10

slide-21
SLIDE 21

Embedded systems are a lot like other systems i.e. built from reusable components

11

slide-22
SLIDE 22

Embedded systems are a lot like other systems i.e. built from reusable components

11

slide-23
SLIDE 23

This is a recipe for disaster

Mixing code from various sources + No isolation mechanisms + Optimizing for performance = Bugs, exploits, meyham

12

slide-24
SLIDE 24

This is a recipe for disaster

Mixing code from various sources + No isolation mechanisms + Optimizing for performance = Bugs, exploits, meyham

12

slide-25
SLIDE 25

This is a recipe for disaster

Mixing code from various sources + No isolation mechanisms + Optimizing for performance = Bugs, exploits, meyham

12

slide-26
SLIDE 26

This is a recipe for disaster

Mixing code from various sources + No isolation mechanisms + Optimizing for performance = Bugs, exploits, meyham

12

slide-27
SLIDE 27

Reusing components is a GOOD thing!

  • Less engineering effort
  • Fewer bugs overall
  • Better interoperability
  • Don’t roll your own crypto
  • ...

13

slide-28
SLIDE 28

What happens when there is a bug?

14

slide-29
SLIDE 29

Isolation in operating systems

Typically achieved with a thread/process-like abstraction:

  • Servers in microkernels
  • SIPs in Singularity
  • HiStar, Docker, etc...
  • Hails, Aeolus, etc...

15

slide-30
SLIDE 30

Isolation in operating systems

Typically achieved with a thread/process-like abstraction:

  • Servers in microkernels
  • SIPs in Singularity
  • HiStar, Docker, etc...
  • Hails, Aeolus, etc...

15

slide-31
SLIDE 31

Why processes?

Provides isolation Provides concurrency and parallelism Convenient to enforce using hardware or language

16

slide-32
SLIDE 32

Why processes?

Provides isolation Provides concurrency and parallelism Convenient to enforce using hardware or language

16

slide-33
SLIDE 33

Why processes?

Provides isolation Provides concurrency and parallelism Convenient to enforce using hardware or language

16

slide-34
SLIDE 34

Why not processes?

Each process needs its own stack and heap. Internal fragmentation: preallocate maximum memory for each process External fragmentation: dynamically allocate blocks Interaction between components requires communication (message passing, RPC...)

17

slide-35
SLIDE 35

Why not processes?

Each process needs its own stack and heap. Internal fragmentation: preallocate maximum memory for each process External fragmentation: dynamically allocate blocks Interaction between components requires communication (message passing, RPC...)

17

slide-36
SLIDE 36

Why not processes?

Each process needs its own stack and heap. Internal fragmentation: preallocate maximum memory for each process External fragmentation: dynamically allocate blocks Interaction between components requires communication (message passing, RPC...)

17

slide-37
SLIDE 37

Why not processes?

Each process needs its own stack and heap. Internal fragmentation: preallocate maximum memory for each process External fragmentation: dynamically allocate blocks Interaction between components requires communication (message passing, RPC...)

17

slide-38
SLIDE 38

Tradeoff granularity for resources

18

slide-39
SLIDE 39

What if we give up concurrency?

main sendPacket sendByte waitDone waitRxRead readByte parsePacket We can isolate components, but we can’t meet timing requirements

19

slide-40
SLIDE 40

What if we give up concurrency?

main sendPacket sendByte waitDone waitRxRead readByte parsePacket We can isolate components, but we can’t meet timing requirements

19

slide-41
SLIDE 41

Tock is for resource-constrained devices

Microcontrollers often have as little as 16KB of memory Timing constraints on the order of a few thousand cycles (apprx 1ms)

20

slide-42
SLIDE 42

Tock is for resource-constrained devices

Microcontrollers often have as little as 16KB of memory Timing constraints on the order of a few thousand cycles (apprx 1ms)

20

slide-43
SLIDE 43

Challenge: How do we isolate concurrent components without incurring a memory/performance overhead for each component? Key idea: Use a single-threaded event system and isolate using language mechanisms

  • Module bounderies
  • Strong encapsulation (hidden constructors)
  • etc...

21

slide-44
SLIDE 44

Challenge: How do we isolate concurrent components without incurring a memory/performance overhead for each component? Key idea: Use a single-threaded event system and isolate using language mechanisms

  • Module bounderies
  • Strong encapsulation (hidden constructors)
  • etc...

21

slide-45
SLIDE 45

Tock Design

An event system:

  • Enqueue all hardware interrupts
  • Never block on I/O, instead separate into events
  • Deliver results to higher layers through callbacks

Built in Rust: type-safe with no runtime a ”zero-cost” abstractions Rust manages memory using affine types (ownership) instead

  • f garbage collection

22

slide-46
SLIDE 46

Tock Design

An event system:

  • Enqueue all hardware interrupts
  • Never block on I/O, instead separate into events
  • Deliver results to higher layers through callbacks

Built in Rust: type-safe with no runtime a ”zero-cost” abstractions Rust manages memory using affine types (ownership) instead

  • f garbage collection

22

slide-47
SLIDE 47

Tock Design

Small TCB*:

  • Hardware abstraction layer (maps I/O registers into types)
  • Platform tree
  • Event scheduler

Most complex components are isolated:

  • Peripheral drivers
  • Virtualization layers (timers, bus virtualization)
  • Applications

23

slide-48
SLIDE 48

Tock Design

Small TCB*:

  • Hardware abstraction layer (maps I/O registers into types)
  • Platform tree
  • Event scheduler

Most complex components are isolated:

  • Peripheral drivers
  • Virtualization layers (timers, bus virtualization)
  • Applications

23

slide-49
SLIDE 49

Dealing with mutability

Mutability and circular dependencies don’t mix well:

  • Unsafe type coersion
  • Use after free
  • Iterator invalidation

Solution: Only allow mutability in controlled ways:

  • Copy-in/copy-out
  • One user-at a time (no ”internal” mutability)

Enforced using Rust’s ”immutable” references

24

slide-50
SLIDE 50

Dealing with mutability

Mutability and circular dependencies don’t mix well:

  • Unsafe type coersion
  • Use after free
  • Iterator invalidation

Solution: Only allow mutability in controlled ways:

  • Copy-in/copy-out
  • One user-at a time (no ”internal” mutability)

Enforced using Rust’s ”immutable” references

24

slide-51
SLIDE 51

Dealing with mutability

Mutability and circular dependencies don’t mix well:

  • Unsafe type coersion
  • Use after free
  • Iterator invalidation

Solution: Only allow mutability in controlled ways:

  • Copy-in/copy-out
  • One user-at a time (no ”internal” mutability)

Enforced using Rust’s ”immutable” references

24

slide-52
SLIDE 52

Tock Implementation

In progress implementations for two platforms: Firestorm

  • SAM4L - 64KB memory
  • 802.15.4 and BLE radios
  • Sensors - temperature, accelerometer, light intensity

NRF51822

  • 16KB memory
  • Bluetooth low energy system-on-a-chip

25

slide-53
SLIDE 53

Tock Implementation

Kernel is <10K lines of Rust 100 lines of assmebly Requires 6KB memory to include all components Performance numbers forthcoming...

26

slide-54
SLIDE 54

Tock Implementation

Kernel is <10K lines of Rust 100 lines of assmebly Requires 6KB memory to include all components Performance numbers forthcoming...

26

slide-55
SLIDE 55

Didn’t talk about

Tock also supports a limited number of processes.

  • Applications in C
  • Legacy drivers

About 8 slots on the SAM4L

27

slide-56
SLIDE 56

Limitations

Legacy code needs to be ported to Rust or take up one of a few processes Concurrency model does not support parallelism

28

slide-57
SLIDE 57

Conclusion

  • Embedded systems need isolation mechanimsms
  • Traditional mechanimsms not appropriate
  • Processes: memory overhead
  • Non-concurrent: timing constraints
  • Tock is a single-threaded event system
  • Low/no overhead per component
  • Retains concurrency

29