Isolation Enforced by the Operating System Based on

Isolation Enforced by the Operating System Based on slides provided by Landon Cox

Isolation of resources • Process memory • Files • (Virtual) Machines

Memory Isolation • Each process works in its own virtual address space • All accesses to physical memory go through the memory management system • The memory management system isolates one process’s memory from the others • The virtual address space allocated to the kernel is shared by all processes, but can’t be accessed directly by a user process

Accessing virtual memory User process Physical memory Page table PTBR CPU Page table base register for current process (PTBR) OS

Accessing virtual memory User process Physical memory Access virtual address Page Physical pages table PTBR CPU OS

Accessing virtual memory User process Physical memory Access virtual address Page Physical pages table PTBR CPU OS Determine if access is allowed

Accessing virtual memory User process Physical memory Access virtual address Page Physical pages table PTBR CPU If OK, retrieve data, execute instruction OS

Accessing virtual memory User process Physical memory Access virtual address Page Physical pages table PTBR CPU If not OK, trap to OS OS

Accessing virtual memory User process Physical memory Access virtual address Page Physical pages table PTBR CPU If not OK, trap to OS OS Determine if access is valid

Accessing virtual memory User process Physical memory If not valid, kill process Access virtual address Page Physical pages table PTBR CPU If not OK, trap to OS OS

Accessing virtual memory User process Physical memory Access virtual address Page Physical pages table PTBR CPU If not OK, trap to OS If not resident, load non-resident page OS

Accessing virtual memory User process Physical memory Access virtual address Page Physical pages table PTBR CPU If not OK, trap to OS If not resident, load non-resident page, update page table OS

Accessing virtual memory Retry faulting instruction User process Physical memory Access virtual address Page Physical pages table PTBR CPU If not OK, trap to OS If not resident, load non-resident page, update page table OS

Multi-level page table Level 1 0 1 NULL Level 2 … 1023 ? NULL 0: Phys. Page, Res, Prot 1: Phys. Page, Res, Prot … ? 1023: Phys. Page, Res, Prot

User/kernel translation data 4 GB Kernel data (same for all page tables) 3 GB (0 xc 0000000) User data (different for every process) 0 GB Virtual memory

Kernel vs. user mode • Who sets up the data used by the memory management unit (MMU)? • Can’t be the user process • Otherwise could access anything • Only kernel is allowed to modify any memory • Processor must know to allow kernel • To update the translator (e. g. , set PTBR) • To execute privileged instructions (halt, do I/O)

Kernel vs. user mode • How does machine know kernel is running? • This requires hardware support • CPU supports different modes, kernel and user • Mode is indicated by a hardware register • Mode bit

Protection recap 1. All memory accesses go through a translator GBs of protected data • Who can modify translator’s data? 2. Only kernel can modify translator’s data • How do we know if kernel is running? 3. Mode bit indicates if kernel is running • Who can modify the mode bit? One bit of protected data Making progress: the amount of protected data is down to a bit

Protecting the mode bit • Can kernel change the mode bit? • Yes. Kernel is completely trusted. • Can user process change the mode bit? • Not directly • User programs need to invoke the kernel • Must be able to initiate a change

When to transition from user to kernel? 1. Exceptions (interrupts, traps) • Access something out of your valid address space • (e. g. , segmentation fault) • Disk I/O finishes, causes interrupt • Timer pre-emption, causes interrupt • Page faults 2. System calls • Similar in purpose to a function call • Kernel as software library

Example system calls • Process management • Fork/exec (start a new process), exit, getpid • Signals • Kill (send a signal), sigaction (set up handler) • Memory management • Brk (extend the valid address space), mmap • File I/O • Open, close, read, write • Network I/O • Accept, send, receive • System management • Reboot

System call implementation • Syscalls are like functions, but different • Implemented by special instruction • Software trap • syscall • Execution of syscall traps to kernel • Processor safely transfers control to kernel • Hardware invokes kernel’s syscall trap handler

Kernel trap details • Hardware must atomically 1. 2. 3. 4. Set processor mode bit to “kernel” Save current registers (SP, PC, general purpose) Change execution stack to kernel (SP) Jump to exception handler in kernel (PC)

Creating, starting a process 1. Allocate process control block 2. Read program code from disk 3. Store program code in memory (could be demand-loaded too) • Physical or virtual memory? • (physical: no virtual memory for process yet) 4. Initialize machine registers for new process 5. Initialize translator data for new address space • E. g. , page table and PTBR • Virtual addresses of code segment point to correct physical locations 6. Set processor mode bit to “user” 7. Jump to start of program Need hardware support

Access control • Where is most trusted code located? • In the operating system kernel • What are the primary responsibilities of a UNIX kernel? • Managing the file system • Launching/scheduling processes • Managing memory • How do processes invoke the kernel? • • Via system calls Hardware shepherds transition from user process to kernel Processor knows when it is running kernel code Represents this through protection rings or mode bit

Access control • How does kernel know if system call is allowed? • • Looks at user id (uid) of process making the call Looks at resources accessed by call (e. g. , file or pipe) Checks access-control policy associated with resource Decides if policy allows uid to access resources • How is a uid normally assigned to a process? • On fork, child inherits parent’s uid

MOO accounting problem • Multi-player game called Moo • Want to maintain high score in a file • Should players be able to update score? • Yes • Do we trust users to write file directly? • No, they could lie about their score Game client (uid x) “x’s score = 10” High score “y’s score = 11” Game client (uid y)

MOO accounting problem • Multi-player game called Moo Game client (uid x) • Want to maintain high score in a file • Could have a trusted process update scores “x’s score = 10” Game server • Is this good enough? “x: 10 y: 11” High score “y’s score = 11” Game client (uid y)

MOO accounting problem • Multi-player game called Moo Game client (uid x) • Want to maintain high score in a file • Could have a trusted process update scores “x’s score = 100” Game server • Is this good enough? • Can’t be sure that reported score is genuine • Need to ensure score was computed correctly “x: 100 y: 11” High score “y’s score = 11” Game client (uid y)

Access control • Insight: sometimes simple inheritance of uids is insufficient • Tasks involving management of “user id” state • Logging in (login) • Changing passwords (passwd) • Why isn’t this code just inside the kernel? • This functionality doesn’t really require interaction w/ hardware • Would like to keep kernel as small as possible • How are “trusted” user-space processes identified? • Run as super user or root (uid 0) • Like a software kernel mode • If a process runs under uid 0, then it has more privileges

Access control • Why does login need to run as root? • Needs to check username/password correctness • Needs to fork/exec process under another uid • Why does passwd need to run as root? • Needs to modify password database (file) • Database is shared by all users • What makes passwd particularly tricky? • Easy to allow process to shed privileges (e. g. , login) • passwd requires an escalation of privileges • How does UNIX handle this? • Executable files can have their setuid bit set • If setuid bit is set, process inherits uid of image file’s owner on exec

MOO accounting problem • Multi-player game called Moo • Want to maintain high score in a file Shell (uid x) “fork/exec game” Game client (uid moo) • How does setuid solve our problem? • • Game executable is owned by trusted entity Game cannot be modified by normal users Users can run executable though High-score is also owned by trusted entity “x’s score = 10” High score (uid moo) • This is a form of trustworthy computing • Only trusted code can update score • Root ownership ensures code integrity • Untrusted users can invoke trusted code “y’s score = 11” Shell (uid y) “fork/exec game” Game client (uid moo)

Coarser abstraction: virtual machine • We’ve already seen a kind of virtual machine • OS gives processes virtual memory • Each process runs on a virtualized CPU • Virtual machine • An execution environment • May or may not correspond to physical reality

How do we virtualize? • Key technique: “trap and emulate” • • Untrusted/user code tries to do something it can’t Transfer control to something that can do it Evaluate whether thing is allowed If so, do it and return control. Else, kill process or throw exception. • Where have we seen trap and emulate? • • • Virtual memory Process tries to access non-resident memory Trap to OS OS makes virtual page resident Retry instruction that caused fault • Generally useful technique, crucial for virtual machines Ways to do this? Rely on HW Rewrite code

Virtual-machine options • Approaches to implementing VMs 1. Interpreted virtual machines • Translate every VM instruction • Kind of like on-the-fly compilation • VM instruction HW instruction(s) 2. Direct execution • Execute instructions directly • Emulate the hard ones

Interpreted virtual machines • Implement the machine in software • Must translate emulated to physical • Java: byte codes x 86, PPC, ARM, etc • Software fetches/executes instructions Program (foo. class) Byte code Interpreter (java) x 86 Looks a lot like a dynamic virtual memory translator

Java virtual machine • What is the (low-level) interface to the JVM? • Java byte-code instructions • What abstraction does the JVM provide? • JVM: Stack-machine architecture • Dalvik (Android): Register-based architecture • The Java programming language • High-level language compiled into byte code • Library of services (kind of like a kernel) • Like PHP, Python, C++/STL, C#

Direct execution • What is the interface? • Hardware ISA (e. g. , x 86 instructions) • What is the abstraction? • Physical machine (e. g. , x 86 processor) x 86 Program (Linux kernel) x 86 Monitor (VMware) x 86

Different techniques • Emulation • Bochs, QEMU • Full virtualization • VMware • Paravirtualization • Xen • Dynamic recompilation • Virtual PC

Views of the CPU • How is a user process’s view of the CPU different than the OS’s? • • • Kernel mode Access to physical memory Manipulation of page tables Other “privileged instructions” Turn off interrupts Traps • Keep these in mind when thinking about virtual machines

Traditional OS structure Ring 3 Ring 0 App App Operating System Host Machine App

Virtual-machine structure Ring 3 Guest App Ring 3? Guest OS Ring 0 Virtual Machine Monitor (Hypervisor) Host Machine

Virtual-machine structure Ring 3 Guest App Ring 1 Guest OS Ring 0 Virtual Machine Monitor (Hypervisor) Host Machine