47
Architectural Support for Operating Systems

Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

  • View
    219

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Architectural Support for Operating Systems

Page 2: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Announcements

• Required textbook should be in Cornell store soon (perhaps this week)

Page 3: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Today’s material

• I/O subsystem and device drivers

• Interrupts and traps

• Protection, system calls and operating mode

• OS structure

• What happens when you boot a computer?

Page 4: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Computer System Architecture

Synchronizes memory access

Page 5: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

I/O operations

• I/O devices and the CPU can execute concurrently.

• I/O is moving data between device & controller’s buffer– CPU moves data between controller’s 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

Page 6: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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?

Page 7: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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)

Page 8: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Polling I/O handshaking:

• To write data to a device:1. Host repeatedly reads busy bit in status register until clear

2. Host sets write bit in command register and writes output in data-out register

3. Host sets command-ready bit in control register

4. Controller notices command-ready bit, sets busy bit in status register

5. Controller reads command register, notices write bit: reads data-out register and performs I/O (magic)

6. Controller clears command-ready bit, clears the error bit (to indicate success) and clears the busy bit (to indicate it’s finished)

Page 9: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Polling I/O

• What’s the problem?

– CPU could spend most its time polling devices, while other jobs go undone.

• But devices can’t be left to their own devices for too long

– Limited buffer at device - could overflow if doesn’t get CPU service.

• Modern operating systems uses Interrupts to solve this dilemma.

• Interrupts: Notification from interface that device needs servicing

– Hardware: sends trigger on bus

– Software: uses a system call

Page 10: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Interrupts

• CPU hardware has a interrupt-request line (a wire) it checks after processing each instruction.

• On receiving signal Save processing state– 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.

• Modern OS needs more sophisticated mechanism:– Ability to defer interrupt– Efficient way to dispatch interrupt handler– Multilevel interrupts to to distinguish between high and low priority

interrupts.

Page 11: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Modern interrupt handling

• Use a specialized Interrupt Controller• CPUs typically have two interrupt request lines:

– Maskable interrupts: Can be turned of by CPU before critical processing

– Nonmaskable interrupts: signifies serious error (e.g. unrecoverable memory error)

• Interrupts contain address pointing to interrupt vector– Interrupt vector contains addresses of specialized interrupt handlers.

– If more devices than elements in interrupt vector; do interrupt chaining: • A list of interrupt handlers for a given address which must be traversed to

determine the appropriate one.

• Interrupt controller also implements interrupt priorities– Higher priority interrupts can pre-empt processing of lower priority ones

Page 12: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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..

Page 13: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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

Page 14: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Example I/O

cach

eCPU (*N)

Thread ofexecution Memory

Instructions and Data

Instruction execution cycle

Data movement

Keyboard Device Driverand

Keyboard Controller

I/O R

equest

Perform I/O

Read Data

Interrupt

Data

Disk Device Driverand

Disk Controller

DMA

Page 15: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Interrupt Timeline

Page 16: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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

Page 17: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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

Page 18: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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

Page 19: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Protecting Memory• Protect program from accessing other program’s data

• Protect the OS from user programs

• Simplest scheme is base and limit registers:

• Virtual memory and segmentation are similar

memory

Prog A

Prog B

Prog C

Base register

Limit register

Loaded by OS before starting program

Page 20: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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, TLB load, etc.

• Setting of special mode bits

• Halt instruction

Needed for:

• Abstraction/ease of use and protection

Page 21: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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 god, 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?

Page 22: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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 process System Call

TrapMode bit = 0

Save Caller’s state Execute system call Restore state

ReturnMode bit = 1

Resume process

User ModeMode bit = 1

Kernel ModeMode bit = 0

Page 23: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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)

Page 24: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Types of System Calls

• Process Control

– end or abort process; create or terminate process, wait for some time; allocate or deallocate memory

• File Management

– open or close file; read, write or seek

• Device Management

– attach or detach device; read, write or seek

• Information Maintenance

– get process information; get device attributes, set system time

• Communications

– create, open, close socket, get transfer status.

Page 25: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Why APIs?System call sequence to copy contents of one file to another

Standard API

Page 26: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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).

Page 27: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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();}

}

Page 28: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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.• Ancient 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)

Page 29: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Fixed Pie, Infinite Demand

• How to divide pie?

– User? Yeah, right.

– Usually treat all apps same, then monitor and re-apportion

• What’s 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.

Page 30: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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” O/S executable

– From hard disk, CD-ROM, or whatever– Then transfers control to a standard start address in this image– The small version of the O/S loads and starts the “big” version.

• The two stage mechanism is used so that BIOS won’t need to understand the file system implemented by the “big” O/S kernel

• File systems are complex data structures and different kernels implement them in different ways

• The small version of the O/S is stored in a small, special-purpose file system that the BIOS does understand

Page 31: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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 (DEC’s VMS on VAX computed Pi)

• OS wakes up on:

– interrupts from hardware devices

– traps from user programs

– exceptions from user programs

Page 32: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

OS Control Flow

Operating System Modules

IdleLoop

From boot

Initialization

RTI

InterruptSystem call

main()

Exception

Page 33: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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 security

Page 34: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

General OS Structure

DeviceDrivers

Extensions &Add’l device drivers

Interrupthandlers

File Systems

Memory Manager

ProcessManager

SecurityModule

API

App App

NetworkSupport

ServiceModule

Boot &init

App

Monolithic Structure

Page 35: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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

Page 36: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Layered Structure

DeviceDrivers

Extensions &Add’l device drivers

Interrupthandlers

File Systems

Memory Manager

ProcessManager

API

App App

NetworkSupport

Boot &init

App

ObjectSupport

M/C dependent basic implementations

Hardware Adaptation Layer (HAL)

Page 37: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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

Page 38: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Microkernel Structure

DeviceDrivers

Extensions &Add’l device drivers

Interrupthandlers

File Systems

Memory Manager

ProcessManager

SecurityModule

App

NetworkSupport

Boot &init

App

Basic Message Passing Support

Page 39: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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

Page 40: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

UNIX structure

Page 41: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Windows Structure

Page 42: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

Modern UNIX Systems

Page 43: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

MAC OS X

Page 44: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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,

CLR, Xen+++

Page 45: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

VMWare Structure

Page 46: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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 can’t tell!

Page 47: Architectural Support for Operating Systems. Announcements Required textbook should be in Cornell store soon (perhaps this week)

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 (by the spyware)?

• Basically: no, it can’t!• Vendors are adding “Trusted Computing

Base” (TCB) technologies to help– Hardware that can’t be virtualized– We’ll discuss it later in the course