Genode Components

Genode OS Framework - Components

Norman Feske<[email protected]>

Outline

1. Classification of components

2. Kernelization example

3. Unified configuration concept

4. Session routing

5. Components overview

Genode OS Framework - Components 2

Outline




4. Session routing



Classification

Kernel enables base platform

Device driver translates device interface to API

Protocol stack translates API to API

Application is leaf node in process tree

Runtime environment has one or more children

Resource multiplexer has multiple clients

combinations are possible


Kernel


Device driver

Translates device interface to session interface

Uses core’s IO MEM, IO PORT, IRQ services

Single client

Contains no policy

Enforces policy (device-access arbitration)


Device driver (2)

Critical because of DMA

MMU protects physical memory from driver codeDriver code accesses device via MMIODevice has access to whole physical memory (DMA)

→ Device driver can access whole physical memory

IOMMUs can help ...but are no golden bullet


Device driver (3)

Even with no IOMMU, isolating drivers has benefits

Taming classes of non-DMA-related bugs

I Memory leaksI Synchronization problems, dead-locksI Flawed driver logic, wrong state machinesI Device initialization

Minimizing attack surface from the outside


Protocol stack

Translates API to another (or the same) API

Does not enforce policy

Single client

May be co-located with device driver


Protocol stack (2)

Libraries

Library Translation

Qt4 Qt4 API → various Genode sessionslwIP socket API → NIC session

Components translating sessions

Component Translation

TCP terminal Terminal session → NIC sessioniso9660 ROM session → Block sessionffat fs File-system session → Block session


Protocol stack (3)

Components that filter sessions


Protocol stack (4)

Operate on session interfaces, not physical resources

→ May be instantiated any number of times

→ Critical for availablility

→ Not neccessarily critical for integrity and confidentiality

→ Information leakage constrained to used interfaces

complex code should go in here


Application

Leaf node in process tree

Uses services

Implements application logic

Provides no service


Runtime environment

Hosts other processes as children

Defines and imposes policy!

Examples

InitVirtual machine monitorDebuggerPython interpreter


Resource multiplexer

Multiplexes session interface

Multiple clients → Potential multi-level component

Free from policy

Enforce policy dictated by parent

Prone to cross-client information leakage

Prone to resource-exhaustion-based DoS


Resource multiplexer (2)

→ Often as critical as the kernel

→ Must be as low complex as possible

→ Must work on client-provided resources

→ Must employ heap partitioning

only a few resource multiplexers needed


Outline




4. Session routing



Kernelizing the GUI server

Persistent security problems of GUIs

Impersonation(Trojan horses, phishing, man in the middle)Spyware(input loggers, arcane observers)Robustness/availability risks(resource-exhaustion-based denial of service

GUI belongs to TCB → low complexity is important!


Starting point: DOpE as secure GUI


DOpE as secure GUI - Drawbacks

Prone to resource exhaustion by malicious clientsProvides custom look and feel*

I Stands in the way when using legacy softwareI May be enhanced by theme support

Complexity of 12,000 LOC


Straight-forward attempt: Shrinking DOpE

Revisiting the implementation

Keeping only essential functionality→ 7,000 LOC

We loose:

Majority of widgets (grid, scale, scrollbar, etc.)Flexible command interfaceCoolness, fancyness, convenienceReal-time support

7,000 LOC are too much for such a crippled GUI!


Bottom-up approach

What do we really need in the GUI server?

Widgets? → NoFont support? → NoWindow decoration? → NoTextual command interface? → NoLook and feel, gradients, translucency? → NoHardware abstractions (e. g., color-space conversion)? → NoWindows displaying pixel buffers? → YESDistribution of input events? → YESSecure labeling? → YES


Buffers and views


User interaction

Input-event handling

Only one receiver of each input eventFocused view defines input routingRouting controlled by the user only


Client-side window handling

Report motion events to focused view while a button is pressed→ Client-side window policies (move, resize, stacking)→ Key for achieving low server-side complexity

Emergency break→ Special key regains control over misbehaving applications


Trusted path

It is not sufficient to label windows!

A Trojan Horse could present an image of a secure windowNot the secure window must be marked, but all others!

Revoke some degree of freedom from the clients

Dedicated screen area, reserved for the trusted GUIRevoking the ability to use the whole color space

→ X-Ray mode, activated by special key (x-ray key)


Trusted path (2)


Nitpicker results

Source-code complexity

GUI server Lines of code

X.org > 80,000Trusted X 30,000DOpE 12,000EWS 4,500Nitpicker < 2,000

Low performance overhead, no additional copyLow-complexity clients are possible (Scout: 4,000 LOC)


Nitpicker results (2)

Support for legacy softwareProtection against spywareHelps to uncover Trojan horsesLow source-code complexity

→ Poster child of a resource multiplexer


Outline




4. Session routing



Traditional approaches to system configuration

Boot-loader configurationI vbeset command in GRUB menu.lst

Command line arguments specified to boot modules

Kernel command line

Custom configuration filesI Needs file providers, file name spaceI Varying syntax → parsing problems


Unified configuration concept


Unified configuration concept (II)


Unified configuration concept (III)

→ Uniform syntax

→ Extensible through custom tags at each level

→ XML parser adds less than 300 LOC to TCB


Outline




4. Session routing



Session routing example

<config>

<parent-provides>

<service name="CAP"/>

<service name="LOG"/>

</parent-provides>

<start name="timer">

<resource name="RAM" quantum="1M"/>

<provides> <service name="Timer"/> </provides>

<route>

<service name="CAP"> <parent/> </service>

</route>

</start>

<start name="test-timer">

<resource name="RAM" quantum="1M"/>

<route>

<service name="Timer"> <child name="timer"/> </service>

<service name="LOG"> <parent/> </service>

</route>

</start>

</config>


Using wildcards

<route>

<service name="ROM"> <parent/> </service>

<service name="RAM"> <parent/> </service>

<service name="RM"> <parent/> </service>

<service name="PD"> <parent/> </service>

<service name="CPU"> <parent/> </service>

</route>

generalized:

<route>

<any-service> <parent/> </any-service>

</route>


Combining wildcards with explicit routes

<route>

<service name="LOG"> <child name="nitlog"/> </service>


</route>


Useful routing template

<route>


<any-service> <any-child/> </any-service>

</route>

abbreviated:

<route>

<any-service> <parent/> <any-child/> </any-service>

</route>


Poly-instantiating the same binary

<start name="nit_fb">

...

<start name="nit_fb"> 

...

ambiguity resolved:

<start name="nit_fb_1">

<binary name="nit_fb"/> 

...

<start name="nit_fb_2"> 

<binary name="nit_fb"/>

...

Routing through hierarchies


Routing through hierarchies (2)

<config>

<parent-provides> ... </parent-provides>

<start name="timer"> <resource name="RAM" quantum="1M"/>

<provides> <service name="Timer"/> </provides>

<route> <service name="CAP"> <parent/> </service> </route>

</start>

<start name="init"> <resource name="RAM" quantum="1M"/>

<config>

<parent-provides>

<service name="Timer"/> <service name="LOG"/>

</parent-provides>

<start name="test-timer"> <resource name="RAM" quantum="1M"/>

<route> <service name="Timer"> <parent/> </service>

<service name="LOG"> <parent/> </service> </route>

</start>

</config>

<route> <service name="Timer"> <child name="timer"/> </service>

<any-service> <parent/> </any-service> </route>

</start>

</config>


Real-time priorities

Kernels provide static priorities

How to make the feature available?

Priorities have side effects on otherwise unrelated subsystemsPriority inversionPriority inversion + time-slice donation = hard-to-find bug


Real-time priorities (2)


Real-time priorities (3)

<config prio_levels="2">

...

<start name="init.1" priority="0">

...

<config prio_levels="4">

...



<start name="init.11" priority="-1"> ... </start>


<start name="init.12" priority="-2">

<config>

<start name="init.121"> ... </start>

</config>

</start>

</config>

</start>


<start name="init.2" priority="-1"> ... </start>

</config>

Configuration concept in practice

DevelopmentWildcards are handyConcise configurations, easy to maintain

DeploymentUse explicit routes only→ Default deny→ Whitelist only permitted session types→ Mandatory access control

Absence of wildcards is easy to validate


Outline




4. Session routing



Interfaces

LOG Unidirectional debug output

Terminal Bi-directional input and outputsynchronous bulk

Timer Facility to block the client

Input Obtain user inputsynchronous bulk

Framebuffer Display pixel buffersynchronous bulk

PCI Represents PCI bus, find and obtain PCI devices


Interfaces (2)

ROM Obtain read-only data modulesshared memory

Block Block-device accesspacket stream

File system File-system accesspacket stream

NIC Bi-directional transfer of network packets2 x packet stream

Audio out Audio outputpacket stream


Device drivers

Session type Location

Timer os/src/drivers/timer

Block os/src/drivers/atapi

os/src/drivers/ahci

os/src/drivers/sd card

dde linux/src/drivers/usb drv

Input os/src/drivers/input/ps2


Framebuffer os/src/drivers/framebuffer/vesa

os/src/drivers/framebuffer/sdl

os/src/drivers/framebuffer/pl11x

os/src/drivers/framebuffer/omap4

Audio out linux drivers/src/drivers/audio out

Terminal os/src/drivers/uart

NIC dde ipxe/src/drivers/nic


PCI os/src/drivers/pci


Resource multiplexers and protocol stacks


LOG os/src/server/terminal log

demo/src/server/nitlog

Framebuffer, demo/src/server/liquid framebuffer

Input os/src/server/nit fb

Nitpicker os/src/server/nitpicker

Terminal os/src/server/terminal crosslink

gems/src/server/terminal

gems/src/server/tcp terminal


Resource multiplexers and protocol stacks (2)


Audio out os/src/server/mixer

NIC os/src/server/nic bridge

ROM os/src/server/rom prefetcher

os/src/server/tar rom

os/src/server/iso9660

Block os/src/server/rom loopdev

os/src/server/part blk

gems/src/server/http block

File system os/src/server/ram fs

libports/src/server/ffat fs


Protocol-stack libraries

API Location

POSIX libports/lib/mk/libc.mk

libports/lib/mk/libc log.mk

libports/lib/mk/libc fs.mk

libports/lib/mk/libc rom.mk

libports/lib/mk/libc lwip.mk

libports/lib/mk/libc ffat.mk

libports/lib/mk/libc lock pipe.mk

libports/lib/mk/libc terminal.mk

Qt4 qt4/lib/mk/qt *

OpenGL libports/lib/mk/gallium.mk


Runtime environments

Runtime Location

Init os/src/init

Loader os/src/server/loader

L4Linux ports-foc/src/l4linux

L4Android ports-foc/src/l4android

OKLinux ports-okl4/src/oklinux

Vancouver ports/src/vancouver

Noux ports/src/noux

GDB Monitor ports/src/app/gdb monitor

Python libports/lib/mk/x86 32/python.mk

Lua libports/lib/mk/moon.mk


Thank you

What we covered todayComponents

1. Classification of components2. Kernelization of the GUI

server3. Unified configuration

concept4. Session routing5. Components overview

Coming up next...Compositions

1. Virtualization techniques2. Enslaving services3. Dynamic workloads

More information and resources:http://genode.org


Genode Components

Education

Transcript of Genode Components