Legacy Containers and OS Personalitiesos.inf.tu-dresden.de/Studium/KMB/WS2009/09-legacy... · 2009. 12. 8. · 2)Resolve name at name server a)Backend calls name server b)Name server

Faculty of Computer Science Institute for System Architecture, Operating Systems Group

Legacy Containers andOS Personalities

Dresden, 2009-12-08

Carsten Weinhold

TU Dresden, 2009-12-08 MOS - Legacy Containers Slide 2

So far...

So far:– Basics Concepts:

● Tasks, Threads, IPC● Memory, Synchronization, ...

– Device Drivers– Real-Time– Resource Management– Virtualization

Today:– Legacy Containers / OS Personalities


Making the Cut ...

Adaptation to underlying system can happen at various levels:

• Hardware level (virtualization):– Legacy OS and applications moved to new OS– faithful + para virtualization, e.g., L4Linux

• OS level:– Legacy OS's interfaces reimplemented on top

of new OS– e.g., Wine on Linux

• Application level:– Toolkits, frameworks, libraries (e.g., Qt)


Straightforward Way to OS Personality

Single-server approach:– All (legacy) system services

provided by a single server (e.g., L4Linux)

– No isolation among services

– Provides high level of compatibility, as original implementations are reused

– Ideally, applications do not need to be modified

Ext2 VFAT IP

Disk Driver NIC Driver

AppApp

Syscall Entry

SingleServer

Microkernel


Multiple Single Servers

• Multiple instances of single-server OSes

• Useful for isolation of applications

• Not necessarily identical OS personalities (e.g., have UNIX and Windows servers)

• “Virtual machines”

UNIX App

SingleServer

UNIX

Microkernel

UNIX App

SingleServer

UNIX

Windows App

SingleServer

Windows


Application Scenarios for Single Server

Hybrid applications (real time):

• “Enlightened” applications:– Major parts of applications

(e.g., GUIs) do not require real-time guarantees

– Small parts (e.g., device controller) may need real-time guarantees, can run next to legacy container

• Examples:– RT network, RT file system,

RT window system / widget

App

SingleServer

Microkernel

Real-TimeInfrastructure

Real-TimeServer


Application Scenarios for Single Server

Hybrid applications (security):

• “Enlightened” applications:– Most parts are not security

critical

– Small parts require strong isolation from potentially insecure legacy container

• Examples:– Cryptographic algorithms and

key handling

App

SingleServer

Microkernel

SecurityInfrastructure

SecurityServer


Virtualized OSes: Recap

• Virtualization allows reuse of OS

• Multiple VMs

• Legacy applications run on top

• Applications are kind of trapped in VM:– Different resource pools– Different namespaces– Cooperation with apps running next to VM

possible, though

• “… but I just want that application running”


A Case for OS Personalities

How is it different from virtualization?● Adaptation above hardware / OS layer● (Re-)implemented APIs instead of whole OS● May require recompilation of the applications

Why?● Reuse existing applications / APIs● Sometimes easier to get it running● Flexibility / Configurability● Better integration (namespaces, files, ...)● Improved reliability● Lower resource consumption


Single Server to Multi Server

Ext2 VFAT IP


AppApp

Ext2 VFAT IP


AppApp

Syscall Entry

Monolith

MicrokernelMicrokernel

Move from single server to multi server

Challenge: Application wants a consistent viewin a distributed system


Approach: Central Server

Ext2 VFAT IP


Process / VFS / Net / ...

AppApp

• Central server provides consistent view for both:– Applications

• System resources (files, ...)

– Servers• Client state (file tables, ...)

• Problem:– Performance bottleneck– Scalability– Complexity


Approach: Emulation Library

Ext2 VFAT IP


AppApp

• Emulation library– Per application– Interacts with servers– Provides consistent view

• Each servers keeps its own client state

• In real world:– Applications use C library,

emulation library hidden below– Emulation provides legacy API

EmulationLibrary

EmulationLibrary

C Library C Library


Legacy Environment: POSIX

• POSIX “Portable Operating System Interface” is a family of standards (POSIX 1003.*)

• POSIX makes various UNIX-like systems compatible (even Windows NT and newer)

• Defines interfaces and properties:– I/O: files, sockets, terminal, ...– Threads / synchronization: PThread– System tools– ...

• POSIX API accessible via C library


C Library on L4Re: uClibc

• L4Re uses uClibc:– Implementation of C library– Designed for Embedded Linux– Compatible to GNU C library “glibc”– Small and portable– Optional C++ support available (uClibc++)– Licensed under LGPL

• Fiasco.OC + L4Re != Linux

• How to port it?


C Library: API to POSIX

• Collection of various common functions• Abstraction layer above system calls

• Functions with different abstraction levels ...– low level: memcpy(), strlen()– medium: fopen(), fread()– high level: getpwent()

• ... and dependencies– none (freestanding): memcpy(), strlen()– small: malloc(): uses mmap() or sbrk()– strong: getpwent(): file access, “/etc/passwd”,

name service, ...


Multi-Server Aware C Library

• Observations:– C library depends on underlying OS– Specific implementation may differ

Application

libc + syscall bindings

Monolithic / Single-Server OS

System Call Interface

MOE

Memory Interface

L4Re::Env::mem_alloc(),L4::L4fs::L4fs::open(), ...L4Re::Env::mem_alloc(),L4::L4fs::L4fs::open(), ...

memcpy(), fopen(),getpwent()

TimeBE

FileBE

MemBE ...

libc

open(), read(),mmap()

FileSystem

File System Interface

Application

+ Backends


C Library Backends: Time

Example 1: POSIX time API• Functions can easily be replaced on L4Reuint64_t __libc_l4_rt_clock_offset;

int libc_be_rt_clock_gettime(struct timespec *tp){ uint64_t clock;

clock = l4re_kip()->clock; clock += __libc_l4_rt_clock_offset;

tp->tv_sec = clock / 1000000; tp->tv_nsec = (clock % 1000000) * 1000;

return 0;}

uint64_t __libc_l4_rt_clock_offset;

int libc_be_rt_clock_gettime(struct timespec *tp){ uint64_t clock;

clock = l4re_kip()->clock; clock += __libc_l4_rt_clock_offset;

tp->tv_sec = clock / 1000000; tp->tv_nsec = (clock % 1000000) * 1000;

return 0;}

time_t time(time_t *t){ struct timespec a;

libc_be_rt_clock_gettime(&a);

if (t) *t = a.tv_sec; return a.tv_sec;}

time_t time(time_t *t){ struct timespec a;

libc_be_rt_clock_gettime(&a);

if (t) *t = a.tv_sec; return a.tv_sec;}

L4Re-specific backend function (called by time()and other POSIX functions)

Replacement oftime() function


C Library Backends: Memory

Example 2: memory management

• uClibc implements heap allocator• Requests memory pages via mmap()• Can be reused, just need to provide mmap()• Multiple implementations possible, e.g.:

– self_mem• Very simple, uses pages from BSS• Set up by allocating static array

– l4re_mem• Full mmap(), munmap(), …• Requests memory as dataspaces


C Library Backends: Signals

Example 3: POSIX signals• Used for asynchronous event notifications

– Timers: setitimer(), ...– Exceptions: SIGFPE, SIGSEGV, SIGCHLD, …– Issued by applications: SIGUSR1, SIGTERM, ...

• Signals on Linux:– Built-in kernel mechanism– Delivered upon return from kernel

• Signals on L4Re:– Implemented in user space– Based on exceptions and IPC timeouts


POSIX Signals on L4Re: Mechanics

• Dedicated thread E handles exceptions and timers

• E is exception handler of thread T

• Exceptions in T are reflected to E

• If app configured signal handler:– E sets up signal handler context– E resets T's program counter to

signal handler– T executes signal handler, returns

• If possible, E restarts T where it had been interrupted

T E

Application A


POSIX Signals on L4Re: Mechanics (2)

• Basic mechanism:– Exceptions are mapped to IPC messages– E waits for exception IPCs in server loop

• Timers implemented as IPC timeouts:– sigaction()/setitimer()/... called in T

– T communicates time to wait to E– E waits for IPC for timeout

– E Raises exception in T to deliver SIGALRM


POSIX Signals on L4Env: kill()

signal server

Application A Application B

Signal backend

Signal Thread(b.04)

register_handler()

register_handler() setup signalhandlers

setup signalhandlerssetup signalhandlers

signal_threads

A a.03

B b.04

Signal backend

Signal Thread(a.03) signal(A,

SIGUSR1)notify(SIGUSR1)


C Library Backend: File I/O

• What's needed for file I/O?– fprintf() support: easy, just replace write()– Minimalist backend can output text

#include <unistd.h>#include <errno.h>

#include <l4/sys/kdebug.h>

int write(int fd, const void *buf, size_t count) __THROW{ /* just accept write to stdout and stderr */ if ((fd == STDOUT_FILENO) || (fd == STDERR_FILENO)) { l4kdb_outnstring((const char*)buf, count); return count; }

/* writes to other fds shall fail fast */ errno = EBADF; return -1;}

#include <unistd.h>#include <errno.h>

#include <l4/sys/kdebug.h>

int write(int fd, const void *buf, size_t count) __THROW{ /* just accept write to stdout and stderr */ if ((fd == STDOUT_FILENO) || (fd == STDERR_FILENO)) { l4kdb_outnstring((const char*)buf, count); return count; }

/* writes to other fds shall fail fast */ errno = EBADF; return -1;}


C Library Backends: File Access

Example 4: POSIX file API• File system access provided by servers• Multiple servers with their own namespaces• Problem: consistent view at namespace

Ext2fsFile System

TerminalServer

File Backend

Application

CryptographicFile System

TemporaryFile System

/

crypto tmpdev

tty

bin lib

certkey

tty1tty0

swap.txt


L4VFS: Distributed Name Service

• Name server● Maps symbolic names -> object

ids: (volume id).(local object id)● Iteratively queries object servers

to resolve names● Maps volume ids to object servers● Manages mount table

• Object server● Maintains locally unique object

IDs (e.g., for files)● Maps names -> local object Ids● Keeps client state file pointer,

access mode, ...)

Object serverExt2fs

Object serverTerminal

Name server

Backend

Application


L4VFS: Mechanics

• Complex I/O backend: L4VFS• Example:

1)App calls open(“/dev/tty1”)2)Resolve name at name server

a)Backend calls name serverb)Name server calls server con_term, gets back reference to tty1

3)Backend opens tty1, server con_term updates client state

4)Backend updates local file table5)Libc returns local file handle

Application (“test1”, 1c.2)

Libc

I/OBack-end

fd_table(12.2):230

12

con_term(12.2)

client_state’tty0’:1c.2:’r’:0

’tty2’:1e.4:’rw’:0

232425

name_server(11.0)

1 5

3

2a

2b

4(12.2):24

’tty1’:1c.2:’w’:0


Configurability of C Library Backends

Unnecessary backends can be omitted:– Applications rely on less components– Potentially better security properties– Most appropriate backend can be chosen

MOE

Memory Interface

ext2Server

File System Interface

TimeBE

FileBE

MemBE ...

libc + Backends

File-System Application

TimeBE

NetBE

MemBE ...

libc + Backends

Network Application

PF_INETServer

Network Interface

PF_LOCALServer

Network Interface

MemBE

libc + Backends

Simple Application


Summary: POSIX Emulation on L4Re

• L4Re offers significant part of POSIX APIs:– C library: strcpy(), …– Dynamic memory allocation

• malloc(), free(), mmap()• Based on dataspaces

– Pthread– Signal handling– I/O support: files, terminal, time, (network)

• POSIX is enabler: sqlite, Cairo, shell, ...


More Powerful Legacy Containers

• POSIX is limited to basic OS abstractions:– No graphics / GUI support– No audio support

• Examples for more powerful APIs:– SDL “Simple Direct Layer”

(focuses on Multimedia)

– Qt toolkit(focuses on rich GUIs and complete OS abstraction)


Qt Toolkit on Microkernel Platforms

• What is Qt?– Multi-platform toolkit library– Provides abstraction of underlying OS– Available for:

● UNIX/X11 (Linux, *BSD, ...)● Windows● Mac OS X● Also ports for: L4Env, L4Re, Genode

• Qt/L4Env based on Qt3 for embedded Linux:– Has its own “Qt Windowing System” (QWS)– Relies on POSIX compliant OS


Qt Architecture

Qt API

File Access

Application

Operating System

Network Threads /Sync GUI ...

POSIX / L4VFS POSIX / L4VFS L4Env thread,semaphore QWS

Platform Independent

Platform Specific


Graphical Console

libinput(Hardware Access)

Qt/L4: Qt Windowing System

• QWS is core part of Qt/L4Env:– Displays and manages windows from multiple

Qt applications– Operates on shared framebuffer– Events distributed via shared memory /

socketsQt App

(+ acts as QWS Server)

Qt library

FBDriver

Keyb.Driver

MouseDriver

Qt App

Qt library

FBDriver

Qt App

Qt library

FBDriver

QWSServerCode


DEMO


Qt/L4Env: Features

• Complete support of GUI framework

• Threads, Synchronization supported

• Support for file access– Depends on available L4VFS file servers

• Support for network access– Basic functionality with L4VFS server “FLIPS”


Qt/L4: Easy Development

• Applications (or parts of them) can be developed and tested on Linux

• Rapid Application Development:– GUIs can be created with Qt Designer– Other tools (e.g, UI compiler) can also usable


Coming up next ...

• Later today:● Compley lab

• Next week: ● Lecture: “Security: Intro”● Practical excercise: “Capability Systems”


Example: Minix 3

Figure from [3]: “Reorganizing UNIX for Reliability”,J. N. Herder, H. Bos, B. Gras, P. Homburg, A. S. Tanenbaum


References

• [1] Carsten Weinhold: 'Portierung von Qt auf DROPS', TU Dresden, Großer Beleg 2005, http://os.inf.tu-dresden.de/paper_ps/weinhold-beleg.pdf

• [2] Resources on POSIX standard:http://standards.ieee.org/regauth/posix/

• [3] J. N. Herder, H. Bos, B. Gras, P. Homburg, A. S. Tanenbaum: 'Reorganizing UNIX for Reliability', Proc. 11th Asia-Pacific Computer Systems Architecture Conference (ACSAC'06), pp. 81--94, Shanghai, China, Sep. 2006. (Advances in Computer Systems Architecture, Springer Lecture Notes in Computer Science (LNCS) 4186.)

http://os.inf.tu-dresden.de/paper_ps/weinhold-beleg.pdf

http://standards.ieee.org/regauth/posix/

Documents

Legacy Containers and OS Personalitiesos.inf.tu-dresden.de/Studium/KMB/WS2009/09-legacy... · 2009. 12. 8. · 2)Resolve name at name server a)Backend calls name server b)Name server