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
)
- Supports variable-sized stack frames (
- 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
- System calls and the
- 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
: PrintsHi, I’m Alice!
and yieldsp-eve
: PrintsHi, I’m Eve!
and yields
WeensyOS commands
make run
ormake 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 typec
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) {}
}
obj/p-eve.asm
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
- Computer turns on
- Built-in hardware initializes the system
- Built-in hardware loads a small, extremely constrained program called the boot loader from a fixed location on attached storage (Flash memory, disk)
- Boot loader initializes the processor and loads the kernel