architectural support for operating systems

47
Architectural Support for Operating Systems

Upload: remedios-knox

Post on 01-Jan-2016

27 views

Category:

Documents


1 download

DESCRIPTION

Architectural Support for Operating Systems. Announcements. 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?. Computer System Architecture. Synchronizes memory access. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Architectural Support for  Operating Systems

Architectural Support for Operating Systems

Page 2: Architectural Support for  Operating Systems

Announcements

Page 3: Architectural Support for  Operating Systems

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

Computer System Architecture

Synchronizes memory access

Page 5: Architectural Support for  Operating Systems

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

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

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

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

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

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

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

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

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

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

Interrupt Timeline

Page 16: Architectural Support for  Operating Systems

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

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

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

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

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

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

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

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

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

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

Standard API

Page 26: Architectural Support for  Operating Systems

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

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

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

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

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

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

OS Control Flow

Operating System Modules

IdleLoop

From boot

Initialization

RTI

InterruptSystem call

main()

Exception

Page 33: Architectural Support for  Operating Systems

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

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

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

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

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

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

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

UNIX structure

Page 41: Architectural Support for  Operating Systems

Windows Structure

Page 42: Architectural Support for  Operating Systems

Modern UNIX Systems

Page 43: Architectural Support for  Operating Systems

MAC OS X

Page 44: Architectural Support for  Operating Systems

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

VMWare Structure

Page 46: Architectural Support for  Operating Systems

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

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