YouTube placeholder

Software Interrupts and Exceptions

Masking Interrupts

  • Hardware interrupts can be either asynchronous or synchronous.

  • Asynchronous interrupts can be ignored or masked.

    • The processor provides an interrupt mask allowing the operating system to choose which interrupts will trigger the ISR.

    • If an interrupt is masked, it will not trigger the ISR.

    • If an interrupt is still asserted when it is unmasked, it will trigger the ISR at that point.

  • Some interrupts are synchronous or not maskable: these typically indicate very serious conditions which must be handled immediately.

    • Example: processor reset.

Why Mask Interrupts?

  • Choosing to ignore interrupts allows the system to prioritize certain interrupts over others.

    • "The DVD write buffer is empty" is more important than "There is a network packet waiting to be processed."

  • In some cases handling certain interrupts generates other interrupts which would prevent the system from handling the original interrupt!

Protecting Interrupt Handlers

  • What would happen if applications were allowed to modify the interrupt service routines?

    • Applications could take control of devices by preventing the kernel from communicating with them. Disaster!

  • Interrupt handlers allow the operating system to control access to hardware devices and protect them from direct control by untrusted applications.

  • The memory that contains interrupt handlers is protected from access by user applications.

  • One of the first things that the kernel does on boot is install its interrupt handlers!

Software Interrupts

Given that the operating system prevents unprivileged code from directly accessing system resources, how do applications gain access to these protected resources?

  • "Hey, over here, I need to read some data from disk!"

  • "I could really use some more memory. Please?"

syscall

  • CPUs provide a special instruction (syscall on the MIPS) that generates a software (or synthetic) interrupt.

  • Software interrupts provide a mechanism for user code to indicate that it needs help from the kernel.

  • Rest of the interrupt handling path is unchanged. The CPU:

    1. enters privileged mode,

    2. records state necessary to process the interrupt,

    3. jumps to a pre-determined memory location and begins executing instructions.

Making System Calls

To access the kernel system call interface an application:

  1. arranges arguments to the system call in an agreed-on place where the kernel can find them, typically in registers or on its stack,

  2. loads a number identifying the system call it wants the kernel to perform into a pre-determined register, and

  3. executes the syscall instruction.

libc provides the wrappers around the syscall instruction that programmers are familiar with.

You can find this code in your OS/161 source tree. Look around!

Software Exceptions

An software exception indicates that code running on the CPU has created a situation that the processor needs help to address.

Can you think of examples of software exceptions?

  • Divide by zero—​probably kills the process.

  • Attempt to use a privileged instruction—​also probably kills the process.

  • Attempt to use a virtual address that the CPU does not know how to translate—​a common exception handled transparently as part of virtual memory management.

Software Exceptions v. Software Interrupts

Interrupts are voluntary.

  • Think of the CPU as saying to the kernel: "The /bin/true process would like your assistance."

Exceptions are non-voluntary.

  • Think of the CPU as saying to the kernel: "I need some help with this /bin/false process. It just tried to divide by zero and I think it needs to be terminated."

Created 2/17/2017
Updated 9/18/2020
Commit 4eceaab // History // View
Built 2/16/2016 @ 19:00 EDT