Kernel 1: Processes, isolation, robustness

Overview

We clean up some assembly topics not reached yet. Then, in this first lecture in the kernel unit, we introduce the goals of operating systems and introduce our tiny operating system.

Full lecture notes on kernel — Textbook readings

The price of passing arguments

• asm/vecsumf03-05.cc

No-ops

Calling convention and red zone

• asm/redzonef01.cc
• asm/redzonef02.cc

Typical stack frame layout

• Be careful about conventions/rules vs. typical usage!
• Calling convention: %rbp is callee-saved
• Typical usage: %rbp acts as a stable pointer near the top of the current function’s stack frame
  • Supports variable-sized stack frames (man alloca)
• But typical usage can differ
  • Optimizer might decide this function benefits from treating %rbp like a normal callee-saved register

System instructions: Debugger

• asm/debugme.cc
• ?!

System instructions: System call

• asm/print.cc
• ?!!

System instructions: The ultimate attack

• asm/loop.cc
• ?!!!

What is behind these mysteries?

The kernel

• All of the software we’ve written so far runs in protected, isolated environments called process environments
• Process environments are restricted in several ways to make the computer as a whole more robust
  • A process cannot monopolize computer resources
  • A process cannot directly access computer hardware
• If a process wants to access hardware, it calls out to a special, more privileged running program called the kernel
• The kernel is the software running with full privilege over the underlying machine hardware
  • The kernel may monopolize computer resources
  • The kernel may directly access computer hardware
  • The kernel should make processes’ lives easier by providing useful abstractions (like files), and by protecting processes from each others’ bugs
  • Different operating systems have different kernels (Linux vs. Mac OS X vs. Windows); processes running on the same operating system interact with the same kernel

Goal: Process isolation

• Process interactions are restricted by operating system policy
  • For instance, processes may interact by reading and writing files
  • Not by overwriting each other’s memory
• A critically important computer systems goal
  • Without it, any bug in any software could cause a “blue screen of death”

Goal: Kernel isolation

• The kernel always retains full privilege over all machine operations
• Unprivileged processes cannot stop the kernel from running
• Unprivileged processes cannot corrupt the kernel

Process isolation’s consequences for hardware design

• There are at least two classes of software running on a computer
  • The kernel has full control over computer resources
  • Processes do not
    • We often call processes unprivileged processes or user processes to highlight this distinction
• Restrictions on processes cannot be enforced by software alone
  • The processor and other computer hardware must have a notion of privilege
  • The processor and other computer hardware must handle privilege violations

Exception: Some experimental systems have fully-trusted source code chains, where, for example, the compiler has been proven correct, and all code running on the machine passes through the trusted compiler. In these systems, it’s theoretically possible to implement process isolation without hardware support.

Some processor features we’ll investigate

• Special instructions for transferring control to the operating system
  • System calls and the syscall instruction
• Hardware features that prevent monopolization of resources
  • Interrupts
  • Privilege modes
• Protection of memory
  • Virtual memory

Why learn about kernels?

• Programmers naturally think about performance and functionality
• Harder to think about security and robustness
  • Keeping a program safe from attackers
  • Limiting the impact of bugs (which are inevitable)
• Kernels sharpen these issues
• Understand how software and hardware interact
• Kernels are super powerful and fun

Alice and Eve in WeensyOS

• p-alice: Prints Hi, I’m Alice! and yields
• p-eve: Prints Hi, I’m Eve! and yields

WeensyOS commands

• make run or make run-PROCESS
  • Run WeensyOS (with a specific first process)
• make stop
  • Stop all WeensyOSes in this Docker environment
• make STOP=1 run + gdb -ix build/weensyos.gdb
  • Run those commands in separate terminals open to the same Docker environment
  • The first command boots WeensyOS, but stops before the kernel gets control
  • In gdb, set breakpoints and type c to continue

Emulation

• WeensyOS runs inside a machine emulator called QEMU
• QEMU is a software program that can behave like a complete x86-64 computer system
  • Interprets instructions, translates input/output to a more convenient format
  • For example, instead of generating electrical signals that could be sent to a television (like the original IBM Personal Computer), QEMU’s emulated display hardware can produce commands understood by the terminal
• QEMU has many other uses too

Eve attacks

        if (n % 1024 == 0) {
            console_printf(CS_YELLOW "Hi, I'm Eve! #%u\n", n);
            while (true) {}
        }

  140046: 89 de                 mov    %ebx,%esi
  140048: be 6d 0c 14 00        mov    $0x141171,%edi
  14004d: b8 00 00 00 00        mov    $0x0,%eax
  140052: e8 10 10 00 00        callq  141067 <console_printf(char const*, ...)>
  140057: 90                    nop
  140058: eb fe                 jmp    140058 <process_main()+0x58>    ; ****

Defending against processor time attack

• Eve is monopolizing processor time
• Needs hardware defense
  • Implementing software defense too expensive
• Timer interrupt
  • An “alarm clock” that goes off N times a second
  • Passes control to kernel via a privileged control transfer
  • Only affects processor in unprivileged mode

Voluntary vs. involuntary privileged control transfer

• syscall: Voluntary control transfer to kernel
  • Process code can save some registers
  • Suitable for calling convention
  • Kernel can modify some registers before returning (e.g., system call return value)
• Timer interrupt: Involuntary control transfer to kernel
  • Can happen after any instruction whatsoever
  • Process code cannot delay or prevent interrupt
  • No calling convention possible
  • Kernel must save and restore all processor registers accessible to processes

Booting: How a computer starts up

1. Computer turns on
2. Built-in hardware initializes the system
3. Built-in hardware loads a small, extremely constrained program called the boot loader from a fixed location on attached storage (Flash memory, disk)
4. Boot loader initializes the processor and loads the kernel