Lecture 2 Architectural Support for OSes CSE 120 Principles of Operating Systems Alex C Snoeren HW 1 Due Tuesday 10 03 Why Architecture Operating systems mediate between applications and the physical hardware of the computer Key goals of an OS are to enforce protection and resource sharing If done well applications can be oblivious to HW details Unfortunately for us the OS is left holding the bag The details of the HW architecture matter Small differences in hardware may have large repercussions Early PC operating systems did not support virtual memory due in large part to the fact that the H W provided no support Sun 1 machines used an entirely separate processor just to manage virtual memory M68000 chips did not have hardware support for virtual memory CSE 120 Lecture 2 Architectural Support for OSes 2 Types of Arch Support Providing protected machine state Generating and handing asynchronous signals Device registers memory management state etc Manipulated with privileged instructions Allows OS to enforce protection Method to respond to external events Interrupts exceptions system calls etc Allows OS to enforce sharing Mechanisms to handle concurrency More on this in a few lectures CSE 120 Lecture 2 Architectural Support for OSes 3 Architectural Features Privileged instructions Protection modes user kernel Memory protection mechanisms Interrupts and exceptions Timer clock I O control and operation System calls Synchronization primitives e g atomic instructions CSE 120 Lecture 2 Architectural Support for OSes 4 Privileged Instructions A select few CPU instructions available only to OS Allows access to protected state Perform global operations For example only the OS should be able to Directly access I O devices disks printers etc Allows OS to enforce security and fairness Manipulate memory management state E g page tables protection bits TLB entries etc Adjusted protected control registers Change between user kernel mode or raise lower interrupt level Execute the halt instruction CSE 120 Lecture 2 Architectural Support for OSes 5 OS Protection How does CPU know when an instruction is OK Architecture must support at least two modes of operation kernel and user mode VAX x86 support four modes rings early archs even more Why Protect the OS from itself software engineering Mode is indicated by a status bit in a protected control register User programs execute in a user mode OS executes in kernel mode OS kernel Protected instructions only execute in kernel mode CPU checks mode bit when protected instruction executes Setting mode bit must be a protected instruction Attempts to execute in user mode are detected and prevented CSE 120 Lecture 2 Architectural Support for OSes 6 Memory Protection OS must be able to protect programs from each other OS must protect itself from user programs Memory management hardware provides protection May or may not protect user programs from OS Base and limit registers Segmentation Page table pointers page protection TLB Virtual memory Manipulating memory management hardware uses protected privileged instructions CSE 120 Lecture 2 Architectural Support for OSes 7 Events An event is an unnatural change in control flow The kernel defines a hander for each event type Event handlers always execute in kernel mode The specific types of events are defined by the machine Events are the only entry into the kernel Events immediately stop current execution Change mode context machine state or both System boot is the first event loads OS Once in user mode only way back to kernel is an event The OS is really just one big event handler CSE 120 Lecture 2 Architectural Support for OSes 8 Types of Events Two kinds of events exceptions and interrupts Exceptions are caused by executing instructions Interrupts are caused by external event Exceptions indicate software intervention is needed Usually hardware devices timers etc Events can be both expected and unexpected Unexpected a k a asynchronous events Sometimes events are caused deliberately CSE 120 Lecture 2 Architectural Support for OSes 9 Types of Events Unexpected Deliberate Exceptions Fault Syscall trap Interrupts H W Interrupt Software interrupt Each type has its own special term Terms vary slightly across architectures OSes Software interrupt is also known as async system trap AST async or deferred procedure call A DPC CSE 120 Lecture 2 Architectural Support for OSes 10 Faults Hardware detects and reports exceptional conditions Upon detecting an exception CPU faults Needs to save context PC registers mode bit etc so that faulting instruction can be resumed OSes use page faults to implement many things Page fault unaligned memory access divide by zero Debugging garbage collection copy on write etc Faults are strictly a performance optimization Not needed for correctness Extra code could be used to test for fault conditions but at significant performance expense CSE 120 Lecture 2 Architectural Support for OSes 11 Handling Faults Some faults are silently fixed by the OS Once exceptional condition is dealt with process resumes E g page faults cause the OS to load the missing page Fault handler reloads the context of the faulting process and reissues the instruction that caused the fault Others are passed on to the application itself OS fault handler modifies the saved context to transfer control to a user mode handler on return from fault Applications must pre register handlers with the OS Unix signals or NT user mode Async Procedure Calls APCs SIGALRM SIGHUP SIGTERM etc CSE 120 Lecture 2 Architectural Support for OSes 12 Fatal Faults Some faults cannot be properly handled OS has no default handler for the particular fault Application also failed to register a handler App is halted state dumped to a core file process destroyed Hopefully such faults do not occur inside the kernel Unhandled faults in the kernel itself are fatal OS crashes Divide by zero dereference NULL pointer invalid instruction etc Unix kernel panic Windows Blue screen of death Kernel is halted state dumped to a core file machine locked up CSE 120 Lecture 2 Architectural Support for OSes 13 System Calls What if an application needs something privileged Application issues a special system call instruction Must ask the OS to perform instruction on its behalf Needs to make a protected procedure call or cross the protection boundary Raises an exception which is trapped by a kernel handler Application passes a parameter which handler reads to determine
View Full Document
Unlocking...