1 of 23

CSE 451

Operating Systems

L4 - Interrupt Handling

Slides by: Tom Anderson

Baris Kasikci

2 of 23

User/Kernel Virtual Addresses

How do we get a program loaded into memory?

When you compile a program you create this thing called an Elf file. Elf stands for executable and linkable format. This is the format for .o files or things you cane execute like .a files. Within this you have various sections called code, data, etc. You also have another section called bss, that’s uninitialized data. Some platforms will zero out this section. Then you have the executable, and some data, that’s initialized data.

Code will be loaded in exactly the location that is specified in the elf file. It’s typically not 0, since that’d be reserved for null pointer dereference.

What are the addresses seen by the kernel?

When I do a system called I am passed arguments in user space. So that can be a pointer to a data structure in user space. So the kernel has visibility into all the user data but also kernel data.

Kernel still has to validate the pointer, because user space can actually pass in a pointer to kernel data.

—

Each process has its own kernel stack.

3 of 23

System Calls

Functions provided by the kernel to untrusted application code

Ex: file open, file read, file write, file close, pipe

Limited set of entry points into the kernel

User code can’t just call any kernel procedure
Protected procedure calls

API is system-specific (UNIX != Windows)

Windows has ~ 2000 system calls
Linux has ~ 800

4 of 23

UNIX systems calls (1972)

Mount, unmount filesystem
File open/create
Seek to a file offset
Read/write file
Close, delete file
Change file owner/mode
Create/delete directory
Add link to file
Ioctl for I/O device operations

Process fork
Process exec
Exit process; wait for exit
Create pipe between processes
Send signal to another process
Set/mask signal handler
Extend heap memory region

5 of 23

6 of 23

Kernel System Call Handler

Locate arguments

In registers or on user stack
Translate user addresses into kernel addresses (if necessary)

Copy arguments

From user memory into kernel memory
Protect kernel from malicious code!

Validate arguments

Protect kernel from errors in user code

Copy results back into user memory

Translate kernel addresses into user addresses (if necessary)

7 of 23

User<->Kernel Transitions

For a static web server to receive a request and reply with the file data?

User to kernel transitions. What happens in terms of syscall and interrupts if a web server were to receive a message from a client, parse that message, go to the filesystem, read the file fill it out and then return it.

There has to be a listen and accept before teh server can start listening. Read from the client. Now the client read will block but since this is handled via an interrupt, the server program can go ahead and do something else. Once the data arrives, the kernel gets an interrupts, writes the buffer somewhere via DMA and returns from the read.

The same thing then will happen wrt the file, so you read the file from disk, then there is a system call. That operation will block until an interrupt is received. When disk is done, it’ll DMA the data into memory.

I think it’s not uncommon for something like the Facebook homepage spends around 60% of time in the kernel. So this stuff should be pretty efficient.

8 of 23

Why dup?

A shell is a user application that runs other programs

% grep “To be or not” Shakespeare.txt

shell creates process “grep”, with arguments; outputs to stdout

% grep “To be or not” Shakespeare.txt > logfile

shell creates process “grep”, with arguments; outputs to logfile

fd = open(“logfile”)

close(stdout)

dup(fd) -> grep uses logfile as its stdout

% grep “To be or not” Shakespeare.txt | wc

Shell creates two processes, “grep” and “wc”

A pipe provides one-way communication between two processes

Shell sets stdout of grep to be one end of pipe; stdin of wc to be the other

9 of 23

Kernel->User Mode Switch

From kernel mode to user mode

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 (UNIX signal)

Asynchronous notification to user program

10 of 23

Restoring User State

We need to be able to interrupt and transparently resume the execution of a user program for several reasons:

I/O device signals I/O completion
Periodic hardware timer to check if app is hung
Multiplexing multiple apps on a single CPU (timer interrupts)
Recoverable exceptions (ex: to extend stack transparently to application)
App unaware it has been interrupted or took an exception!

11 of 23

How do we take interrupts/exceptions safely?

Interrupt vector

Limited number of entry points into kernel
User code can’t jump to an arbitrary location (eg, past privilege checks)

Atomic transfer of control

Hardware saves/restores:

Program counter
Stack pointer
Memory protection
Kernel/user mode

Interrupt handler saves/restores additional registers

Transparent restartable execution

User program does not know interrupt/exception occurred

12 of 23

Interrupt Vector on x86

13 of 23

Kernel (Interrupt) Stack

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

Runs the trap/interrupt/exception/syscall handler
Every process needs both a kernel interrupt stack and user stack
Multiple threads: multiple kernel interrupt stacks

Why can’t the interrupt handler run on the stack of the

interrupted user process?

14 of 23

Interrupt Stack

15 of 23

Interrupt Masking

Interrupt handler runs with interrupts off

Re-enabled when interrupt completes

OS kernel can also turn interrupts off

Eg., when determining the next process/thread to run
On x86

CLI: disable interrrupts
STI: enable interrupts
Only applies to the current CPU (on a multicore)

We’ll need this to implement synchronization in chapter 5

16 of 23

Interrupt Handlers

“Non-blocking”, run to completion

Minimum necessary to allow device to take next interrupt
Any waiting must be limited duration
Wake up other threads to do any real work

Linux: semaphore

Rest of device driver runs as a kernel thread

17 of 23

Case Study: x86 Interrupt (Hardware Support)

Hardware saves current stack pointer (of the user)
Saves current program counter
Saves current processor status word (info about processors: condition codes)
Switches to kernel stack
Puts SP, PC, PSW on stack
Switches to kernel mode
Vectors through interrupt table
Interrupt handler saves registers it might clobber

18 of 23

Before Interrupt

19 of 23

During Interrupt

20 of 23

After Interrupt

21 of 23

xk

vectors.S – why do some vectors push 2 arguments and some push 1?
trapasm.S – looks like callee save, but who saves the PC and SP?
trap.h – on stack so items at bottom of struct pushed first
trap.c – called once trapframe is set up
trapasm.S:trapret -- where call to trap returns

22 of 23

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 mode

23 of 23

Question

Suppose the OS over-writes a value in the trapframe. What happens when the handler returns?

Why might the OS want to do this?