Operating Systems Engineering

Recitation 2: Boot and first process

Based on MIT 6.828 (2014, lec3-5) Focus on xv6

• An educational OS based on UNIX V6 • only a few abstractions \ services • Processes • File system • I/O (via file descriptors) Power on (“boot”) the machine

● Initial state – nothing in RAM, need to read kernel from disk ● BIOS in charge, start bootloader (sheets 84-85) – copy first “boot” sector to 0x7c00 in mem – boot sector = bootasm.S + bootmain.c – executing at end of bootasm.S – stack below 0x7c00, so we can call into C – call bootmain xv6 – bootloader (1)

● Bootloader in charge: – bootmain() – sheet 85 ● Two jobs: – copy kernel from disk to mem (0x100000 phys addr)

● not file–-sectors, raw disk ● linker writes in ELF format – jump to kernel's first instruction

● elf->entry ● objdump -f kernel or readelf -e kernel ● kernel.ld and entry.S xv6 – bootloader (2)

● Why phys address 0x100000 (1MB)? – can't use 0x0 → memory mapped devices 0x0->1M – can use 0x200000 (2MB)?

● yes! it is possible ● Bootloader can load kernel to phys address if – it is a DRAM address – kernel must be able to find itself ● 0x100000 satisfies both conditions xv6 – bootloader (3)

● Where bootmain jumps? – entry->elf_entry from ELF header – not 0x100000 but 0x10000c

● this is "start", in entry.S, sheet 10 – linker put 0x10000c in the ELF header ● (gdb) b *0x10000c (entry.S)

● (gdb) si ● continue and then si to jmp *%eax

● (gdb) #0 0x801033b2 in main () at main.c:19 xv6 – processes

• Process has user space memory: – instructions - actual computation flow – data - variables used in computation – stack – organize procedures calls • Per-process state private to the kernel – page table – kernel stack – file descriptor table xv6 – Process Isolation

• Prevent process X from spying on Y • Prevent process X from corrupting Y – Separated memory, file descriptors – Prevent resource exhaustion (fairness) • Protect kernel from processes • Defensive tactic – Against buggy programs – Against malicious programs xv6 – Isolation Mechanisms

• User/Kernel mode flag • System call abstraction • Address spaces • Timeslicing User/Kernel Mode Flag

• Called CPL in x86 • Bottom two bits of the cs register

cs: CPL

• CPL=0 – kernel mode – privileged • CPL=3 – user mode – not privileged User/Kernel Mode Flag

● CPL is the base to almost every isolation – CPL in low 2 bits of CS – CPL=0 -> can modify cr*, devices, can use any PTE – CPL=3 -> can't modify cr*, or use devs, and PTE_U enforced ● Writes to control registers (cs, for instance)

● Writes to certain flags

● Memory access

● I/O Port access

● However, setting CPL=3 is not enough

● Kernel needs to manage policy System calls

● Call from user to kernel – needs to change CPL

● Can this be done? – set CPL=0 – jump sys_open() ● How about a combined instruction that forces the user to jump to a kernel address? System calls - x86 solution

● Kernel sets allowed entry points

● int instruction sets CPL=0 and jumps – saves the values of cs and eip on stack – system call returns with iret – restores old cs and eip ● Should these instructions be privileged? xv6 – First Process (1)

● Each process state in struct proc (2103) ● Process states – UNUSED, EMBRYO, SLEEPING, RUNNABLE, RUNNING, ZOMBIE ● Each process address space maps – program memory (<0x80000000) – kernel instructions and data (>0x80100000) xv6 – First Process

● Each process has two stacks: user and kernel

● Thread of execution (aka thread) – p->kstack + code – p->state – p->pgdir ● When in user mode kernel stack empty

● When in kernel (syscall) user stack contains data but not used – thread state stored in kernel stack:

● local variables ● return address xv6 – Virtual Memory Layout

● 0x80000000=KERNBASE ● memlayout.h (0207) xv6 – First Address Space

● main.c → main() sheet 12 ● First process (see userinit, 2252) – allocproc() sheet 22, set up stack for "returning" to user space

● save trapret (3027) ● p->context->eip = forkret (2533) , ret will run forkret ● forkret will return to trapret (3027), then to userpace – Fill in kernel part of address space (setupkvm) – Fill in user part of address space

● 1 page containing initcode (see initcode.S) – Setup trapframe to exit kernel

● User-mode bit ● tf->eip = 0 (beginning of initcode.S) ● User-stack lives at top of 1 page of initcode – Set process to runnable xv6 – trap frame

● Kernel stack after allocproc()

● Ready to return to user space

● trapasm.S (3027) : trapret: popal popl %gs popl %fs popl %es popl %ds addl $0x8, %esp # trapno # and errcode iret xv6 – First System Call exec()

● initcode.S (7708) calls exec “/init”

● Instruction int enters kernel again

● System call exec (3207) – replace initcode with /init binary – run /init which

● creates new console ● start shell ● handles orphaned zombies ● system is up Questions? Backup Slides xv6 – A Monolithic Kernel

• Kernel is a big program • Contains all services, low level hardware mechanisms • Entire kernel runs with full privileges • Pros – easy kernel subsystem interactions • Cons – complex interactions => bugs => system crash – no isolation in the kernel • Unix, Linux, BSD family, Solaris, xv6 Micro Kernel

• Kernel is a small program – A micro kernel tries to run most services as daemons in user space. • Only kernel runs with full privileges • Microkernel is essentially a high speed context-switching engine

• Pros – complex service interactions => bugs => service crash but system alive! – kernel isolated from services, services isolated from user • Cons – complex OS subsystem interactions using IPC – a lot of of messaging and context switching involved ● MINIX, QNX, L4 Exo Kernel

• Kernel is a very small program – concept of an exokernel is orthogonal to that of micro- vs. monolithic kernels. – there are no forced abstractions – security separated from abstraction • Kernel and users can run with full privileges • Pros – simplicity and performance – freedom: users can implement their own optimal subsystems • Cons – additional effort from users and system maintainers ● JOS, nonkernel, BareMetal OS