Operating Systems Introduction, Processes, Threads Daniel Gruss October 2, 2020 Table of contents www.tugraz.at 1. Basics 2. History 3. Booting 4. Process and Thread Fundamentals 5. Context Switches 6. Process and Thread Organization 1 Basics What is an Operating System www.tugraz.at 2 What is an Operating System www.tugraz.at 3 What is an Operating System www.tugraz.at 4 What is an Operating System www.tugraz.at Run on all sorts of devices: Servers, Desktops, Notebooks Tablets, Smartphones Routers, Switches, Displays Door Locks, Washing Machines, Toasters Cars, Airplanes .... We focus on general purpose operating systems 5 Operating System Roles www.tugraz.at Referee Illusionist Glue 6 Operating System Roles: Referee www.tugraz.at Referee Manage resource allocation among users and applications Isolation of different users, applications from each other Isolation of applications and operating system Communication between users, application 7 Operating System Roles: Illusionist www.tugraz.at Illusionist Abstraction of hardware and other things Makes application design simpler Each application appears to have the entire machine to itself Illusion of Infinite number of processors (near) infinite amount of memory reliable storage reliable network transport 8 Operating System Roles: Glue www.tugraz.at Glue Libraries, user interface widgets, . 9 Example: File Systems www.tugraz.at Referee Prevent users from accessing each other's files without permission Even after a file is deleted and its space re-used Illusionist Files can grow (nearly) arbitrarily large Files persist even when the machine crashes in the middle of a save 10 Example: File Systems www.tugraz.at Glue Nam ed directories, printf, . 11 OS Design Patterns I www.tugraz.at OS challenges are not unique - apply to many different computing domains many complex software systems have multiple users run programs written by third-party developers need to coordinate simultaneous activities 12 OS Design Patterns II www.tugraz.at Challenges: resource allocation fault isolation communication abstraction how to provide a set of common services 13 Reliability and Availability Security Portability Performance Adoption Design Criteria for OS www.tugraz.at Design Criteria for Operating Systems 14 Security Portability Performance Adoption Design Criteria for OS www.tugraz.at Design Criteria for Operating Systems Reliability and Availability 14 Portability Performance Adoption Design Criteria for OS www.tugraz.at Design Criteria for Operating Systems Reliability and Availability Security 14 Performance Adoption Design Criteria for OS www.tugraz.at Design Criteria for Operating Systems Reliability and Availability Security Portability 14 Adoption Design Criteria for OS www.tugraz.at Design Criteria for Operating Systems Reliability and Availability Security Portability Performance 14 Design Criteria for OS www.tugraz.at Design Criteria for Operating Systems Reliability and Availability Security Portability Performance Adoption 14 It does, what it is designed to do Application failures can be \ok" - OS provides fault isolation and clean restart after errors OS errors are bad, real bad... Reliability and Availability www.tugraz.at Reliability 15 Application failures can be \ok" - OS provides fault isolation and clean restart after errors OS errors are bad, real bad... Reliability and Availability www.tugraz.at Reliability It does, what it is designed to do 15 Reliability and Availability www.tugraz.at Reliability It does, what it is designed to do Application failures can be \ok" - OS provides fault isolation and clean restart after errors OS errors are bad, real bad... 15 hostile environment (viruses, malicious code take control) testing helps - but is much more difficult extremely rare corner cases can occur regularly Reliability www.tugraz.at Making an OS reliable is challenging 16 Reliability www.tugraz.at Making an OS reliable is challenging hostile environment (viruses, malicious code take control) testing helps - but is much more difficult extremely rare corner cases can occur regularly 16 Percentage of time the system is usable Buggy OS that loses users work is unreliable AND unavailable Buggy OS that never loses users work is reliable BUT unavailable Buggy OS that has been subverted but continues to run (and e.g. logs keystrokes and sends them of) is available BUT unreliable Availability www.tugraz.at Availability 17 Buggy OS that loses users work is unreliable AND unavailable Buggy OS that never loses users work is reliable BUT unavailable Buggy OS that has been subverted but continues to run (and e.g. logs keystrokes and sends them of) is available BUT unreliable Availability www.tugraz.at Availability Percentage of time the system is usable 17 Availability www.tugraz.at Availability Percentage of time the system is usable Buggy OS that loses users work is unreliable AND unavailable Buggy OS that never loses users work is reliable BUT unavailable Buggy OS that has been subverted but continues to run (and e.g. logs keystrokes and sends them of) is available BUT unreliable 17 Reliability and Availability www.tugraz.at Reliablity and Availability are desireable Two factors: MTTF: mean time to failure MTTR: mean time to repair 18 Security www.tugraz.at Security: computers operation cannot be compromised by a malicious attacker Privacy: data stored on the computer is only accessible to authorized users 19 Security www.tugraz.at Unfortunately: no useful computer is perfectly secure! OS is a complex piece of software complex software has bugs bugs can be exploited HW may be tampered with Sysadmin may be untrustworthy SW-developer may be untrustworthy (backdoors) 20 Security www.tugraz.at OS should be designed to minimize its vulnerability to attack Fault isolation But: interaction between users and programs required 21 Security Policy www.tugraz.at Security Policy defines who can access what data who can perform what operations 22 Policies and Enforcement may possess vulnerabilities... Enforcement www.tugraz.at Enforcment ensures that policy is followed 23 Enforcement www.tugraz.at Enforcment ensures that policy is followed Policies and Enforcement may possess vulnerabilities... 23 does not change as the hardware changes Portability is an important design criteria of the OS don't want to reimplement everything when HW changes e.g. iOS was derived from the MacOS X code base Portability www.tugraz.at OS provides an abstraction of underlying HW 24 Portability is an important design criteria of the OS don't want to reimplement everything when HW changes e.g. iOS was derived from the MacOS X code base Portability www.tugraz.at OS provides an abstraction of underlying HW does not change as the hardware changes 24 don't want to reimplement everything when HW changes e.g. iOS was derived from the MacOS X code base Portability www.tugraz.at OS provides an abstraction of underlying HW does not change as the hardware changes Portability is an important design criteria of the OS 24 e.g. iOS was derived from the MacOS X code base Portability www.tugraz.at OS provides an abstraction of underlying HW does not change as the hardware changes Portability is an important design criteria of the OS don't want to reimplement everything when HW changes 24 Portability www.tugraz.at OS provides an abstraction of underlying HW does not change as the hardware changes Portability is an important design criteria of the OS don't want to reimplement everything when HW changes e.g. iOS was derived from the MacOS X code base 24 Windows 10 based on Windows NT (started 1988) MS/DOS introduced 1981 - phased out ~2000 First Linux release 1991 Portability www.tugraz.at Lifetime of successful operating systems measured in decades 25 MS/DOS introduced 1981 - phased out ~2000 First Linux release 1991 Portability www.tugraz.at Lifetime of successful operating systems measured in decades Windows 10 based on Windows NT (started 1988) 25 First Linux release 1991 Portability www.tugraz.at Lifetime of successful operating systems measured in decades Windows 10 based on Windows NT (started 1988) MS/DOS introduced 1981 - phased out ~2000 25 Portability www.tugraz.at Lifetime of successful operating systems measured in decades Windows 10 based on Windows NT (started 1988) MS/DOS introduced 1981 - phased out ~2000 First Linux release 1991 25 Portability www.tugraz.at An OS must be designed to support applications that have not yet been written and hardware that has not been developed Simple, standard way for applications to interact with OS API memory access model instructions that can be executed 26 Example for a highly portable OS? Hardware Abstraction Layer www.tugraz.at in older/more theoretical literature sometimes \Abstract Virtual Machine" provides fixed point across which both application and hardware can develop independently 27 Hardware Abstraction Layer www.tugraz.at in older/more theoretical literature sometimes \Abstract Virtual Machine" provides fixed point across which both application and hardware can develop independently Example for a highly portable OS? 27 Performance www.tugraz.at Performance associated with application - OS design can affect the percieved performance OS decides when app can run how much memory it gets etc. Performance can be measured in different ways Overhead / Efficiency Added (lack of) cost of implementing an abstraction presented to applications