The Kernel Abstraction Main Points - PowerPoint Presentation

Slide1

The Kernel AbstractionSlide2

Main Points

Process concept

A process is an OS abstraction for executing a program with limited privileges

Dual-mode operation: user vs. kernel

Kernel-mode: execute with complete privileges

User-mode: execute with fewer privileges

Safe control transfer

How do we switch from one mode to the other?Slide3

Processes

Fundamental abstraction of program execution

memory

processor(s)

each processor abstraction is a

thread

“execution context”Slide4

Process Concept

Process: an instance of a program, running with limited rights

Process control block: the data structure the OS uses to keep track of a process

Two parts to a process:

Thread: a sequence of instructions within a process

Potentially many threads per process (for now 1:1)

Thread aka lightweight process

Address space: set of rights of a process

Memory that the process can access

Other permissions the process has (e.g., which procedure calls it can make, what files it can access)Slide5

A Program

const

int

nprimes

= 100;

int

prime[

nprimes

];

int

main() {

int

i

;

int

current = 2;

prime[0] = current;

for

(

i

=1;

i

<

nprimes

;

i

++) {

int

j;

NewCandidate

:

current++;

for

(j=0; prime[j]*prime[j] <= current; j++) {

if (current % prime[j] == 0)

goto

NewCandidate

;

}

prime[

i

] = current;

}

return

(0);

}Slide6

The Unix Address Space

text

data

bss

dynamic

stackSlide7

Typical Process Layout

Libraries provide the glue between user processes and the OS

libc linked in with all C programs

Provides printf, malloc, and a whole slew of other routines necessary for programs

OBJECT1

OBJECT2

Stack

Heap

Data

Text

HELLO WORLD

GO BIG RED CS!

printf(char * fmt, …) {

create the string to be printed

SYSCALL 80

}

malloc() { … }

strcmp() { … }

main() {

printf (“HELLO WORLD”);

printf(“GO BIG RED CS”);

!

Program

Library

Activation RecordsSlide8

Full System Layout

The OS is omnipresent and steps in where necessary to aid application execution

Typically resides in high memory

When an application needs to perform a privileged operation, it needs to invoke the OS

OBJECT1

OBJECT2

Stack

Heap

Data

HELLO WORLD

GO BIG RED CS!

printf(char * fmt, …) {

main() { … }

Program

Library

Activation Records

USER OBJECT1

OBJECT2

OS Stack

OS Heap

OS Data

LINUX

syscall_entry_point() { … }

OS Text

Kernel Activation RecordsSlide9

Process ConceptSlide10

other stuff

kernel stack

other stuff

kernel stack

other stuff

kernel stack

other stuff

kernel stack

Multiple Processes

kernel textSlide11

Memory ProtectionSlide12

Memory ProtectionSlide13

Towards Virtual Addresses

Problems with base and bounds?Slide14

Virtual Addresses

Translation done in hardware, using a table

Table set up by operating system kernelSlide15

Privileged InstructionsSlide16

Privileged instructions

Examples?

What should happen if a user program attempts to execute a privileged instruction?Slide17

Thought Experiment

How can we implement execution with limited privilege?

Execute each program instruction in a simulator

If the instruction is permitted, do the instruction

Otherwise, stop the process

Basic model in

Javascript

, …

How do we go faster?

Run the unprivileged code directly on the CPU?Slide18

Privilege Levels

Some processor functionality cannot be made accessible to untrusted user applications

e.g. HALT,

Read from disk,

set clock, reset devices, manipulate device settings, …

Need to have a designated mediator between untrusted/untrusting applications

The operating system (OS)

Need to delineate between untrusted applications and OS code

Use a “privilege mode” bit in the processor

0 = Untrusted = user, 1 = Trusted = OSSlide19

Privilege Mode

Privilege mode bit indicates if the current program can perform privileged operations

On system startup, privilege mode is set to 1, and the processor jumps to a well-known address

The operating system (OS) boot code resides at this address

The OS sets up the devices, initializes the MMU, loads applications, and resets the privilege bit before invoking the application

Applications must transfer control back to OS for privileged operationsSlide20

Challenge: Protection

How do we execute code with restricted privileges?

Either because the code is buggy or if it might be malicious

Some examples:

A

script running in a web browser

A

program you just downloaded off the Internet

A program you just wrote that you haven’t tested yetSlide21

Hardware Support:

Dual-Mode Operation

Kernel mode

Execution with the full privileges of the hardware

Read/write to any memory, access any I/O device, read/write any disk sector, send/read any packet

User mode

Limited privileges

Only those granted by the operating system

kernel

On the x86, mode stored in EFLAGS registerSlide22

A Model of a CPUSlide23

A CPU with Dual-Mode OperationSlide24

Hardware Support:

Dual-Mode Operation

Privileged instructions

Available to kernel

Not available to user code

Limits on memory accesses

To prevent user code from overwriting the kernel

Timer

To regain control from a user program in a loop

Safe way to switch from user mode to kernel mode, and vice versaSlide25

Atomic Instructions

Hardware needs to provide special instructions to enable concurrent programs to operate correctlySlide26

Virtual Address Layout

Plus shared code segments, dynamically linked libraries, memory mapped files, …Slide27

Example: Corrected

(What Does this Do?)

int

staticVar

= 0; // a static variable

main() {

int

localVar

= 0; // a procedure local variable

staticVar

+= 1; localVar += 1;

sleep(10); // sleep causes the program to wait for x seconds printf ("static address: %x

, value: %d\n", &staticVar, staticVar);

printf ("procedure local address: %x, value: %d\n", &

localVar, localVar);}

Produces:

static address: 5328, value: 1

procedure local address: ffffffe2, value: 1Slide28

Hardware Timer

Switch between hardware and kernelSlide29

Hardware Timer

Hardware device that periodically interrupts the processor

Returns control to the kernel timer interrupt handler

Interrupt frequency set by the kernel

Not by user code!

Interrupts can be temporarily deferred

Not by user code!

Crucial for implementing mutual exclusionSlide30

Question

For

a

“Hello world” program, the kernel must copy the string from the user

program memory

into the screen memory. Why must the screen’s buffer memory be protected?

Slide31

Question

Suppose we had a perfect object-oriented language and compiler, so that only an object’s methods could access the internal data inside an object. If the operating system only ran programs written in that language, would it still need hardware memory address protection?

Slide32
Slide33

Context switch between user-mode and kernel

Slide34

Mode Switch

From user-mode to kernel

Interrupts

Triggered by timer and I/O devices

Exceptions

Triggered by unexpected program behavior

Or malicious behavior!

System calls (

a

ka protected procedure call)

Request by program for kernel to do some operation on its behalf

Only limited # of very carefully coded entry pointsSlide35

Mode Switch

From kernel-mode to user

New process/new thread start

Jump to first instruction in program/thread

Return from interrupt, exception, system call

Resume suspended execution

Process/thread context switch

Resume some other process

User-level

upcall

Asynchronous notification to user programSlide36

Context switch

InterruptsSlide37

Basic Computer Organization

CPU

Memory

?Slide38

Keyboard

Let’s build a keyboard

Lots of mechanical switches

Need to convert to a compact form (binary)

We’ll use a special mechanical switch that, when pressed, connects two wires simultaneouslySlide39

Keyboard

When a key is pressed, a 7-bit key identifier is computed

+

3-bit

encoder

(4 to 3)

4-bit

encoder

(16 to 4)

not all 16 wires are shownSlide40

Keyboard

A latch can store the keystroke indefinitely

+

3-bit

encoder

(4 to 3)

4-bit

encoder

(16 to 4)

not all 16 wires are shown

LatchSlide41

Keyboard

The keyboard can then appear to the CPU as if it is a special memory address

+

3-bit

encoder

(4 to 3)

4-bit

encoder

(16 to 4)

not all 16 wires are shown

Latch

CPUSlide42

Device Interfacing Techniques

Memory-mapped I/O

Device communication goes over the memory bus

Reads/Writes to special addresses are converted into I/O operations by dedicated device hardware

Each device appears as if it is part of the memory address space

Programmed I/O

CPU has dedicated, special instructions

CPU has additional input/output wires (I/O bus)

Instruction specifies device and operation

Memory-mapped I/O is the predominant device interfacing technique in useSlide43

Polling vs. Interrupts

One design is the

CPU constantly needs to read the keyboard latch memory location to see if a key is pressed

Called

polling

Inefficient

An alternative is to add extra circuitry so the keyboard can alert the CPU when there is a

keypress

Called

interrupt driven I/O

Interrupt driven I/O enables the CPU and devices to perform tasks concurrently, increasing throughput

Only needs a tiny bit of circuitry and a few extra wires to implement the “alert” operationSlide44

Interrupt Driven I/O

CPU

Memory

An interrupt controller mediates between competing devices

Raises an interrupt flag to get the CPU’s attention

Identifies the interrupting device

Can disable (aka mask) interrupts if the CPU so desires

intr

dev id

Interrupt

ControllerSlide45

Interrupt Management

Interrupt controllers manage interrupts

Maskable interrupts: can be turned off by the CPU for critical processing

Nonmaskable interrupts: signifies serious errors (e.g. unrecoverable memory error, power out warning, etc)

Interrupts contain a descriptor of the interrupting device

A priority selector circuit examines all interrupting devices, reports highest level to the CPU

Interrupt controller implements interrupt priorities

Can optionally remap priority levelsSlide46

How do we take interrupts safely?

Interrupt vector

Limited number of entry points into kernel

Kernel interrupt stack

Handler works regardless of state of user code

Interrupt masking

Handler is non-blocking

Atomic transfer of control

Single instruction to change:

P

rogram counter

Stack pointer

Memory protection

Kernel/user mode

Transparent restartable executionUser program does not know interrupt occurredSlide47

Interrupt Vector

Table set up by OS kernel; pointers to code to run on different eventsSlide48

Interrupt Masking

Interrupt handler runs with interrupts off

Reenabled

when interrupt completes

OS kernel can also turn interrupts off

Eg

., when determining the next process/thread to run

If defer interrupts too long, can drop I/O

eventsSlide49

Interrupt Handlers

Non-blocking, run to completion

M

inimum necessary to allow device to take next interrupt

Any waiting must be limited duration

Wake up other threads to do any real work

Pintos:

semaphore_up

Rest of device driver runs as a kernel thread

Queues work for interrupt handler

(Sometimes) wait for interrupt to occurSlide50

Atomic Mode

Transfer

Context Switch

On interrupt (x86)

Save current stack pointer

Save current program counter

Save current processor status word (condition codes)

Switch to kernel stack; put SP, PC, PSW on stack

Switch to kernel mode

Vector through interrupt table

Interrupt handler saves registers it might clobberSlide51

BeforeSlide52

DuringSlide53

AfterSlide54

At end of handler

Handler restores saved registers

Atomically return to interrupted process/thread

Restore program counter

Restore program stack

Restore processor status word/condition codes

Switch to user modeSlide55

Exceptional Situations

System calls are control transfers to the OS, performed under the control of the user application

Sometimes, need to transfer control to the OS at a time when the user program least expects it

Division by zero,

Alert from the power supply that electricity is about to go out,

Alert from the network device that a packet just arrived,

Clock notifying the processor that the clock just ticked,

Some of these causes for interruption of execution have nothing to do with the user application

Need a (slightly) different mechanism, that allows resuming the user applicationSlide56

Interrupts & Exceptions

On an interrupt or exception

Switches the

stack pointer

to the kernel stack

Saves the old (user) SP value

Saves the old (user)

Program Counter

value

Saves the old privilege mode

Saves cause of the interrupt/exception

Sets the new privilege mode to 1

Sets the new PC to the kernel

interrupt/exception handler

Kernel interrupt/exception handler handles the event

Saves

all

registersExamines the cause

Performs operation requiredRestores all registers

Performs a “

return from interrupt

” instruction, which restores the privilege mode, SP and PCSlide57

BeforeSlide58

AfterSlide59

Interrupt Stack

Per-processor, located in kernel (not user) memory

Usually a thread has both: kernel and user stack

Why can’t interrupt handler run on the stack of the interrupted user process?Slide60

Interrupt StackSlide61

Context switch

System CallsSlide62

System Calls

A system call is a controlled transfer of execution from unprivileged code to the OS

A potential alternative is to make OS code read-only, and allow applications to just jump to the desired system call routine. Why is this a bad idea?

A SYSCALL instruction transfers control to a system call handler at a fixed addressSlide63

System Calls

write(fd, buf, len)

kernel text

other stuff

kernel stack

trap into kernel

User portion of address space

Kernel portion of address spaceSlide64

System Calls

Sole interface between user and kernel

Implemented as library routines that execute

trap

instructions to enter kernel

Errors indicated by

returns

of

–1; error code is in

errno

if

(write(

fd

, buffer,

bufsize

) == –1) {// error!

printf("error %d\n", errno);

// see perror

}Slide65

Sample System Calls

Print character to screen

Needs to multiplex the shared screen resource between multiple applications

Send a packet on the network

Needs to manipulate the internals of a device whose hardware interface is unsafe

Allocate a page

Needs to update page tables & MMUSlide66

Syscall vs. Interrupt

The differences lie in how they are initiated, and how much state needs to be saved and restored

Syscall requires much less state saving

Caller-save registers are already saved by the application

Interrupts typically require saving and restoring the full state of the processor

Because the application got struck by a lightning bolt without anticipating the control transferSlide67

System CallsSlide68

Kernel System Call Handler

Locate arguments

In registers or on user(!) stack

Copy arguments

From user memory into kernel memory

Protect kernel from malicious code evading checks

Validate arguments

Protect kernel from errors in user code

Copy results back

into user memorySlide69

SYSCALL instruction

SYSCALL instruction does an atomic jump to a controlled location

Switches the sp to the kernel stack

Saves the old (user) SP value

Saves the old (user) PC value (= return address)

Saves the old privilege mode

Sets the new privilege mode to 1

Sets the new PC to the kernel syscall handler

Kernel system call handler carries out the desired system call

Saves callee-save registers

Examines the syscall number

Checks arguments for sanity

Performs operation

Stores result in v0

Restores callee-save registers

Performs a “return from syscall” instruction, which restores the privilege mode, SP and PCSlide70

Web Server ExampleSlide71

System BootSlide72

System Boot

Operating system must be made available to hardware so hardware can start it

Small piece of code –

bootstrap loader

, locates the kernel, loads it into memory, and starts it

Sometimes two-step process where

boot block

at fixed location loads bootstrap loader

When power initialized on system, execution starts at a fixed memory location

Firmware used to hold initial boot codeSlide73

BootingSlide74

Virtual MachinesSlide75

Virtual Machines

A

virtual machine

takes the layered approach to its logical conclusion. It treats hardware and the operating system kernel as though they were all hardware

A virtual machine provides an interface

identical

to the underlying bare hardware

The operating system

host

creates the illusion that a process has its own processor and (virtual memory)

Each

guest

provided with a (virtual) copy of underlying computerSlide76

Virtual MachineSlide77

Virtual Machines (Cont)

(a) Nonvirtual machine (b) virtual machine

Non-virtual Machine

Virtual MachineSlide78

User-Level Virtual Machine

How does VM Player work?

Runs as a user-level application

How does it catch privileged instructions, interrupts, device I/O, …

Installs kernel driver, transparent to host kernel

Requires administrator privileges!

Modifies interrupt table to redirect to kernel VM code

If interrupt is for VM,

upcall

If interrupt is for another process, reinstalls interrupt table and resumes kernelSlide79

Context switch

System

UpcallsSlide80

Upcall: User-level interrupt

AKA UNIX signal

Notify user process of event that needs to be handled right away

Time-slice for user-level thread manager

Interrupt delivery for VM player

Direct analogue of kernel interrupts

Signal handlers – fixed entry points

Separate signal stack

Automatic save/restore registers – transparent resume

Signal masking: signals disabled while in signal handlerSlide81

Upcall: BeforeSlide82

Upcall: AfterSlide83

Terminology

Trap

Any kind of a control transfer to the OS

Syscall

Synchronous, program-initiated control transfer from user to the OS to obtain service from the OS

e.g. SYSCALL

Exception

Asynchronous, program-initiated control transfer from user to the OS in response to an exceptional event

e.g. Divide by zero, segmentation fault

Interrupt

Asynchronous, device-initiated control transfer from user to the OS

e.g. Clock tick, network packet