Legacy Containers and OS Personalities Carsten Weinhold Dresden, - PDF document

Faculty of Computer Science Institute for System Architecture, Operating Systems Group Legacy Containers and OS Personalities Carsten Weinhold Dresden, 2007-12-18 So far... So far: – Basics Concepts: ● Tasks, Threads, IPC ● Memory, Synchronization, ... – Device Drivers – Real-Time – Naming – Virtualization Today: – Legacy Containers / OS Personalities TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 2 von 34

Motivation What are legacy containers / OS personalities? ● Emulation environment ● Allow to run legacy applications How is it different from virtualization? ● Adaptation can be above hardware / OS layer ● Often requires recompilation of the application Why? ● Reuse existing applications on new OS ● Reuse existing APIs for new applications ● Flexibility / Configurability ● Lower resource consumption TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 3 von 34 Where to Cut? Adaptation to underlying system can happen at various levels: • Hardware level (virtualization): – Legacy OS and applications are moved to new OS (full + para virtualization, e.g., L 4 Linux) • OS level: – Legacy OS's interfaces are reimplemented on top of new OS (e.g., Wine on Linux) • Application level: – Toolkits, framework (e.g., Qt) TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 4 von 34

Straightforward Way to OS Personality Single-server approach: App App – All (legacy) system services provided by a single server Single Server (e.g., L 4 Linux) Syscall Entry – No isolation among services Ext2 VFAT IP – Provides high level of compatibility, as original Disk Driver NIC Driver implementations are reused – Ideally, applications do not need to be modified Microkernel TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 5 von 34 Application Scenarios for Single Server Hybrid applications (real time): App • “Enlightened” applications: – Major parts of applications (e.g., GUIs) do not require Single real-time guarantees Server Real-Time Server – Small parts may require real- time services running next to Real-Time Infrastructure legacy container • Examples: Microkernel – RT network, RT file system, Window with RT widget TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 6 von 34

Application Scenarios for Single Server Hybrid applications (security): App • “Enlightened” applications: – Most parts are not security critical Single Server – Small parts require strong Security Server isolation from potentially insecure legacy container Security Infrastructure • Examples: – Secure file system that Microkernel encrypts all data More in following lectures! TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 7 von 34 Multiple Single Servers • Multiple instances of single-server OSes UNIX App UNIX App Windows App • Useful for isolation of applications Single Single Single Server Server Server • Not necessarily UNIX UNIX Windows identical OS personalities (e.g., have UNIX and Windows servers) Microkernel • “Virtual machines” TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 8 von 34

Single Server to Multi Server Move from single server to multi server App App App App Monolith Syscall Entry Ext2 VFAT IP Ext2 VFAT IP Disk Driver NIC Driver Disk Driver NIC Driver Microkernel Microkernel Challenge: Application wants a consistent view in a distributed system TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 9 von 34 Approach: Central Server • Central server provides consistent view for both: – Applications App App • System resources (files, ...) – Servers • Client state (file tables, ...) Process / VFS / Net / ... • Problem: – Performance bottleneck Ext2 VFAT IP – Scalability Disk Driver NIC Driver – Complexity TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 10 von 34

Approach: Emulation Library • Emulation library – Per application – Interacts with servers App App – Provides consistent view C Library C Library • Each servers keeps its own Emulation Emulation Library Library client state • In real world: – Applications use C library, Ext2 VFAT IP emulation library hidden below Disk Driver NIC Driver – Emulation provides POSIX API TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 11 von 34 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 TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 12 von 34

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, ... TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 13 von 34 Multi-Server Aware C Library • Observations: – C library depends on underlying OS – Specific implementation may differ Application Application memcpy(), fopen(), getpwent() libc + Backends open(), read(), Mem File Time ... libc + syscall bindings mmap() BE BE BE l4vfs_*(), rtc_*(), Memory File System System Call Interface Interface Interface dm_phys_*(), ... Memory Monolithic / File Single-Server OS Server System TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 14 von 34

Example: uClibc on L4 • What is uClibc? – Reimplementation of C library – Designed for Embedded Linux – Compatible to GNU C library “glibc” • Why uClibc? – Small and portable – Optional C++ support available (uClibc++) – Licensed under LGPL • uClibc + backends provide applications with a consistent view of L4-based multi-server OS TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 15 von 34 C Library Backends • C library functions grouped in backends • Simple example: time unsigned int offset; void l4libc_init_time(void) 1. Initalization { Call time server int ret; l4_calibrate_tsc(); ret = l4rtc_get_offset_to_realtime(&offset); if (ret != 0) { extern unsigned int offset; /* RTC server not found, time_t time(time_t *t) /* assuming 1/1/1970, 0:00 */ { offset = 0; time_t t_temp; } l4_uint32_t s, ns; } l4_tsc_to_s_and_ns(l4_rdtsc(), &s, &ns); /* get (cached) system time offset */ t_temp = s + offset; 2. Usage: if (t) *t = t_temp; Locally calculate time (no return t_temp; call to time server necessary) } TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 16 von 34

Flexibility of C Library Backends Multiple implementations for some backends: – Memory backends: • self_mem • sigma0_mem, sigma0_pool_mem • simple_mem • buddy_slab_mem, • TLSF (real-time memory allocator) – I/O backends: • minimal_log_io, io TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 17 von 34 Example: Minimalist I/O Backend • Minimalist I/O backend: – Simple backend for writing to STDOUT/STDERR – Uses L4/Fiasco kernel debugger #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; } TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 18 von 34

Example: Complex I/O Backend Application • Complex L4VFS I/O backend: (“test1”, 1c.2) Libc 1 5 1)App test1 's libc calls open () I/O fd table 2)Resolve name at name server Back- 0 (12.2):23 4 end 1 (12.2):24 (12.2):24 a)Backend calls name server 2 3 b)Name server calls server con_term , gets back con_term (12.2) client_state reference to tty1 23 ’vc2’:1c.2:’r’:0 2a ’vc2’:1c.2:’w’:0 24 3)Backend opens tty1 , server 25 ’vc5’:1e.4:’rw’:0 con_term updates client state 2b name_server 4)Backend updates local file table (11.0) 5)Backend returns file handle TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 19 von 34 Example: POSIX signals on L4 • Signals used to deliver asynchronous event notifications – CPU exceptions (SIGFPE, ...) – Kernel exceptions (SIGSEGV, SIGCHLD, ...) – Issued by applications (SIGUSR1, SIGUSR2, SIGTERM, ...) • Signals on Linux – built-in kernel mechanism – delivered upon return from kernel • Signals on L4 – implement in user space – map signals to L4 IPC? – Problem: IPC is synchronous! TU Dresden, 2007-12-18 MOS - Legacy Containers Slide 20 von 34