Architectural Support for Operating Systems

1
Architectural Support for Operating Systems
2
Announcements

• Most office hours are finalized
• Assignments (if any) up every Tuesday
• Due one week later
• Main TA to contact about assignments Nazrul Alam
• Also contact Levent Kartaltepe
• CS 4411 sections started yesterday
• Oliver Kennedy is instructor
• intro to the course and goals for the term
• Overview of project and details on the first part
  of the project
• C for Java programmers
• syntax and similarities
• common pitfalls
• C software engineering
• Optional architecture review session
• Sometime later this week. Date, time, and
  location, TBD.

3
Announcements

• Make sure you are registered for CS 4410 and/or
  4411
• First CS 4411 project is up
• Initial design documents due next Monday,
  September 8th
• Project due following Wednesday, September 17th
• First CS 4410 homework will be available later
  tonight
• Due next Tuesday, September 9th
• Everyone should have access to CMS
• (http//cms.csuglab.cornell.edu)
• Check and contact me (hweather_at_cs.cornell.edu) or
  Bill Hogan (whh_at_cs.cornell.edu) today if you do
  not have access to CMS
• Also, everyone should have CSUGLab account
• Contact Bill or I if you do not

4
Review History of OS

• Why Study?
• To understand how user needs and hardware
  constraints influenced (and will influence)
  operating systems
• Several Distinct Phases
• Hardware Expensive, Humans Cheap
• Eniac, Multics
• Hardware Cheaper, Humans Expensive
• PCs, Workstations, Rise of GUIs
• Hardware Really Cheap, Humans Really Expensive
• Ubiquitous devices, Widespread networking
• Rapid Change in Hardware Leads to changing OS
• Batch ? Multiprogramming ? Timeshare ? Graphical
  UI ? Ubiquitous Devices ? Cyberspace/Metaverse/??
• Gradual Migration of Features into Smaller
  Machines
• Situation today is much like the late 60s
• Small OS 100K lines/Large 10M lines (5M
  browser!)
• 100-1000 people-years

5
Review Migration of OS Concepts and Features
6
Review Implementation Issues(How is the OS
implemented?)

• Policy vs. Mechanism
• Policy What do you want to do?
• Mechanism How are you going to do it?
• Should be separated, since policies change

7
Goals for Today and Next Lecture

• I/O subsystem and device drivers
• Interrupts and traps
• Protection, system calls and operating mode
• OS structure
• What happens when you boot a computer?

8
Computer System Architecture
Synchronizes memory access
9
I/O operations

• I/O devices and the CPU can execute concurrently.
• I/O is moving data between device controllers
  buffer
• CPU moves data between controllers buffer main
  memory
• Each device controller is in charge of certain
  device type.
• May be more than one device per controller
• SCSI can manage up to 7 devices
• Each device controller has local buffer, special
  registers
• A device driver for every device controller
• Knows details of the controller
• Presents a uniform interface to the rest of OS

10
Accessing I/O Devices

• Memory Mapped I/O
• I/O devices appear as regular memory to CPU
• Regular loads/stores used for accessing device
• This is more commonly used
• Programmed I/O
• Also called channel I/O
• CPU has separate bus for I/O devices
• Special instructions are required
• Which is better?

11
Polling I/O

• Each device controller typically has
• Data-in register (for host to receive input from
  device)
• Data-out (for host to send output to device)
• Status register (read by host to determine device
  state)
• Control register (written by host to invoke
  command)

12
Polling I/O handshaking

• To write data to a device
• Host repeatedly reads busy bit in status register
  until clear
• Host sets write bit in command register and
  writes output in data-out register
• Host sets command-ready bit in control register
• Controller notices command-ready bit, sets busy
  bit in status register
• Controller reads command register, notices write
  bit reads data-out register and performs I/O
  (magic)
• Controller clears command-ready bit, clears the
  error bit (to indicate success) and clears the
  busy bit (to indicate its finished)

13
Polling I/O

• Whats the problem?
• CPU could spend most its time polling devices,
  while other jobs go undone.
• But devices cant be left to their own devices
  for too long
• Limited buffer at device - could overflow if
  doesnt get CPU service.
• Modern operating systems use Interrupts to solve
  this dilemma.

14
Interrupts

• CPU hardware has a interrupt-request line (a
  wire) it checks after processing each
  instruction.
• On receiving signal save processing state
• Save current context
• Jump to interrupt handler routine at fixed
  address in memory
• Interrupt handler
• Determine cause of interrupt.
• Do required processing.
• Restore state.
• Execute return from interrupt instruction.
• Device controller raises interrupt, CPU catches
  it, interrupt handler dispatches and clears it.
• Most operating systems are interrupt-driven
• Hardware sends trigger on bus
• Software uses a system call

15
Even interrupts are sometimes to slow

• Device driver loads controller registers
  appropriately
• Controller examines registers, executes I/O
• Controller signals I/O completion to device
  driver
• Using interrupts
• High overhead for moving bulk data (i.e. disk
  I/O)
• One interrupt per byte..

16
Direct Memory Access (DMA)

• Transfer data directly between device and memory
• No CPU intervention
• Device controller transfers blocks of data
• Interrupts when block transfer completed
• As compared to when byte is completed
• Very useful for high-speed I/O devices

17
Example I/O
Memory Instructions and Data
Instruction execution cycle
Thread of execution
cache
Data movement
CPU (N)
I/O Request
Interrupt
DMA
Data
Keyboard Device Driver and Keyboard Controller
Disk Device Driver and Disk Controller
Perform I/O
Read Data
18
Interrupt Timeline
19
Modern interrupt handling

• Modern OS needs more sophisticated mechanism
• Ability to defer interrupt
• Efficient way to dispatch interrupt handler
• Multilevel interrupts to distinguish between high
  and low priority
• Higher priority interrupts can pre-empt
  processing of lower priority ones
• Use a specialized Interrupt Controller
• CPUs typically have two interrupt request lines
• Maskable interrupts Can be turned off before
  critical processing
• Nonmaskable interrupts cannot be turned off
• Signifies serious error (e.g. unrecoverable
  memory error)
• Interrupts contain address pointing to interrupt
  vector
• Interrupt vector contains addresses of interrupt
  handlers.
• If more devices than elements in interrupt
  vector, then chain
• A list of interrupt handlers for a given address
  which must be traversed to determine the
  appropriate one.

20
Traps and Exceptions

• Software generated interrupt
• Exception user program acts silly
• Caused by an error (div by 0, or memory access
  violation)
• Just a performance optimization
• Trap user program requires OS service
• Caused by system calls
• Handled similar to hardware interrupts
• Stops executing the process
• Calls handler subroutine
• Restores state after servicing the trap

21
Goals for Today and Next Lecture

• I/O subsystem and device drivers
• Interrupts and traps
• Protection, system calls and operating mode
• OS structure
• What happens when you boot a computer?

22
Why Protection?

• Application programs could
• Start scribbling into memory
• Get into infinite loops
• Other users could be
• Gluttonous
• Evil
• Or just too numerous
• Correct operation of system should be guaranteed
• ? A protection mechanism

23
Preventing Runaway Programs

• Also how to prevent against infinite loops
• Set a timer to generate an interrupt in a given
  time
• Before transferring to user, OS loads timer with
  time to interrupt
• Operating system decrements counter until it
  reaches 0
• The program is then interrupted and OS regains
  control.
• Ensures OS gets control of CPU
• When erroneous programs get into infinite loop
• Programs purposely continue to execute past time
  limit
• Setting this timer value is a privileged
  operation
• Can only be done by OS

24
Protecting Memory

• Protect program from accessing other programs
  data
• Protect the OS from user programs
• Simplest scheme is base and limit registers
• Virtual memory and segmentation are similar

memory
Prog A
Base register
Loaded by OS before starting program
Prog B
Limit register
Prog C
25
Virtual Memory / Segmentation

• Here we have a table of base and limit values
• Application references some address x
• CPU breaks this into a page number and an offset
  (or a segment number and offset)
• (More common) Pages have fixed size, usually 512
  bytes
• (Now rare) Segments variable size up to some
  maximum
• Looks up the page table entry (PTE) for this
  reference
• PTE tells the processor where to find the data in
  memory (by adding the offset to the base address
  in the PTE)
• PTE can also specify other things such as
  protection status of page, which end it starts
  at if the page is only partially filled, etc.

26
Protected Instructions

• Also called privileged instructions. Some
  examples
• Direct user access to some hardware resources
• Direct access to I/O devices like disks,
  printers, etc.
• Instructions that manipulate memory management
  state
• page table pointers, translation look-aside
  buffer (TLB) load, etc.
• Setting of special mode bits
• Halt instruction
• Needed for
• Abstraction/ease of use and protection

27
Dual-Mode Operation

• Allows OS to protect itself and other system
  components
• User mode and kernel mode
• OS runs in kernel mode, user programs in user
  mode
• OS is supreme being, the applications are
  peasants
• Privileged instructions only executable in kernel
  mode
• Mode bit provided by hardware
• Can distinguish if system is running user code or
  kernel code
• System call changes mode to kernel
• Return from call using RTI resets it to user
• How do user programs do something privileged?

28
Crossing Protection Boundaries

• User calls OS procedure for privileged
  operations
• Calling a kernel mode service from user mode
  program
• Using System Calls
• System Calls switches execution to kernel mode

User Mode Mode bit 1
Resume process
User process
System Call
Trap Mode bit 0
Kernel Mode Mode bit 0
Return Mode bit 1
Save Callers state
Execute system call
Restore state
29
System Calls

• Programming interface to services provided by the
  OS
• Typically written in a high-level language (C or
  C)
• Mostly accessed by programs using APIs
• Three most common APIs
• Win32 API for Windows
• POSIX API for POSIX-based systems (UNIX, Linux,
  Mac OS X)
• Java API for the Java virtual machine (JVM)
• Why use APIs rather than system calls?
• Easier to use

30
Why APIs?
System call sequence to copy contents of one file
to another
Standard API
31
Reducing System Call Overhead

• Problem The user-kernel mode distinction poses a
  performance barrier
• Crossing this hardware barrier is costly.
• System calls take 10x-1000x more time than a
  procedure call
• Solution Perform some system functionality in
  user mode
• Libraries (DLLs) can reduce number of system
  calls,
• by caching results (getpid) or
• buffering ops (open/read/write vs. fopen/fread/
  fwrite).

32
Real System Have Holes

• OSes protect some things, ignore others
• Most will blow up when you run
• Usual response freeze
• To unfreeze, reboot
• If not, also try touching memory
• Duality Solve problems technically and socially
• Technical have process/memory quotas
• Social yell at idiots that crash machines
• Similar to security encryption and laws

int main() while (1) fork()
33
Fixed Pie, Infinite Demands

• How to make the pie go further?
• Resource usage is bursty! So give to others when
  idle.
• Eg. When waiting for a webpage! Give CPU to idle
  process.
• 1000 years old idea instead of one classroom per
  student, restaurant per customer, etc.
• BUT, more utilization ? more complexity.
• How to manage? (1 road per car vs. freeway)
• Abstraction (different lanes), Synchronization
  (traffic lights), increase capacity (build more
  roads)
• But more utilization ? more contention.
• What to do when illusion breaks?
• Refuse service (busy signal), give up (VM
  swapping), backoff and retry (Ethernet), break
  (freeway)

34
Fixed Pie, Infinite Demand

• How to divide pie?
• User? Yeah, right.
• Usually treat all apps same, then monitor and
  re-apportion
• Whats the best piece to take away?
• Oses are the last pure bastion of fascism
• Use system feedback rather than blind fairness
• How to handle pigs?
• Quotas (leland), ejection (swapping), buy more
  stuff (microsoft products), break (ethernet, most
  real systems), laws (freeway)
• A real problem hard to distinguish responsible
  busy programs from selfish, stupid pigs.

35
Summary Protecting Processes from Each Other

• Problem Run multiple applications in such a way
  that they are protected from one another
• Goal
• Keep User Programs from Crashing OS
• Keep User Programs from Crashing each other
• Keep Parts of OS from crashing other parts?
• (Some of the required) Mechanisms
• Dual Mode Operation
• Address Translation (base/limit registers, page
  tables, etc)
• Privileged instructions (set timer, I/O, etc)
• Simple Policy
• Programs are not allowed to read/write memory of
  other Programs or of Operating System

36
Summary Dual Mode Operation

• Hardware provides at least two modes
• Kernel mode (or supervisor or protected)
• User mode Normal programs executed
• Some instructions/ops prohibited in user mode
• Example cannot modify page tables in user mode
• Attempt to modify ? Exception generated
• Transitions from user mode to kernel mode
• System Calls, Interrupts, Other exceptions

37
Todays Lectures

• I/O subsystem and device drivers
• Interrupts and traps
• Protection, system calls and operating mode
• OS structure
• What happens when you boot a computer?

38
Operating System Structure

• An OS is just another kind of program running on
  the CPU a process
• It has main() function that gets called only once
  (during boot)
• Like any program, it consumes resources (such as
  memory)
• Can do silly things (like generating an
  exception), etc.
• But it is a very sophisticated program
• Entered from different locations in response to
  external events
• Does not have a single thread of control
• can be invoked simultaneously by two different
  events
• e.g. sys call an interrupt
• It is not supposed to terminate
• It can execute any instruction in the machine

39
How do you start the OS?

• Your computer has a very simple program
  pre-loaded in a special read-only memory
• The Basic Input/Output Subsystem, or BIOS
• When the machine boots, the CPU runs the BIOS
• The BIOS, in turn, loads a small OS executable
• From hard disk, CD-ROM, or whatever
• Then transfers control to a standard start
  address in this image
• The small version of the OS loads and starts the
  big version.
• The two stage mechanism is used so that BIOS
  wont need to understand the file system
  implemented by the big OS kernel
• File systems are complex data structures and
  different kernels implement them in different
  ways
• The small version of the OS is stored in a small,
  special-purpose file system that the BIOS does
  understand

40
What does the OS do?

• OS runs user programs, if available, else enters
  idle loop
• In the idle loop
• OS executes an infinite loop (UNIX)
• OS performs some system management profiling
• OS halts the processor and enter in low-power
  mode (notebooks)
• OS computes some function (DECs VMS on VAX
  computed Pi)
• OS wakes up on
• interrupts from hardware devices
• traps from user programs
• exceptions from user programs

41
OS Control Flow
From boot
main()
System call
Initialization
Interrupt
Exception
Idle Loop
Operating System Modules
RTI
42
Operating System Structure

• Simple Structure MS-DOS
• Written to provide the most functionality in the
  least space
• Applications have directcontrol of hardware
• Disadvantages
• Not modular
• Inefficient
• Low protection or security

43
General OS Structure
API
Process Manager
Network Support
Service Module
Monolithic Structure
44
Layered Structure

• OS divided into number of layers
• bottom layer (layer 0), is the hardware
• highest (layer N) is the user interface
• each uses functions and services of only
  lower-level layers
• Advantages
• Simplicity of construction
• Ease of debugging
• Extensible
• Disadvantages
• Defining the layers
• Each layer adds overhead

45
Layered Structure
API
Object Support
Network Support
Process Manager
Machine dependent basic implementations
Hardware Adaptation Layer (HAL)
Boot init
46
Microkernel Structure

• Moves as much from kernel into user space
• User modules communicate using message passing
• Benefits
• Easier to extend a microkernel
• Easier to port the operating system to new
  architectures
• More reliable (less code is running in kernel
  mode)
• More secure
• Example Mach, QNX
• Detriments
• Performance overhead of user to kernel space
  communication
• Example Evolution of Windows NT to Windows XP

47
Microkernel Structure
Process Manager
Network Support
Basic Message Passing Support
48
Modules

• Most modern OSs implement kernel modules
• Uses object-oriented approach
• Each core component is separate
• Each talks to the others over known interfaces
• Each is loadable as needed within the kernel
• Overall, similar to layers but with more flexible
• Examples Solaris, Linux, MAC OS X

49
UNIX structure
50
Windows Structure
51
Modern UNIX Systems
52
MAC OS X
53
Virtual Machines

• Implements an observation that dates to Turing
• One computer can emulate another computer
• One OS can implement abstraction of a cluster of
  computers, each running its own OS and
  applications
• Incredibly useful!
• System building
• Protection
• Cons
• implementation
• Examples
• VMWare, JVM

54
VMWare Structure
55
But is it real?

• Can the OS know whether this is a real computer
  as opposed to a virtual machine?
• It can try to perform a protected operation but
  a virtual machine monitor (VMM) could trap those
  requests and emulate them
• It could measure timing very carefully but
  modern hardware runs at variable speeds
• Bottom line you really cant tell!

56
Modern version of this question

• Can the spyware removal program tell whether it
  is running on the real computer, or in a virtual
  machine environment created just for it?
• Basically no, it cant!
• Vendors are adding Trusted Computing Base (TCB)
  technologies to help
• Hardware that cant be virtualized
• Well discuss it later in the course

57
Summary OS Structure

• Monolithic
• Advantages performance
• Disadvantages difficult to extend, debug,
  secure, and make reliable
• Layered
• Advantages simplicity of construction,
  debugging, and extensible
• Disadvantages defining layers, performance
  overhead
• Micro-kernel
• Advantages easy to extend, port. More reliable
  and secure.
• Disadvantage performance overhead
• Modular
• Advantages monolithic performance with layered
  flexibility
• Disadvantages modules can still crash system
• Virtual Machines
• Advantages protection/isolation, great systems
  building tool
• Disadvantage difficult to implement