Virtualization 101 - Operating Systems Basics

class: center, middle
background-image: url(include/title-background.svg)
# .right[Virtualisation 101]
## .right[Operating Systems    
Basics]

.right[Pierre Olivier]
.right[[pierre.olivier@manchester.ac.uk](mailto:pierre.olivier@manchester.ac.uk)]

---
# Motivation

- Virtualisation consists in **running several operating systems (OSes) on the same computer**
--

- To understand virtualisation we need to understand:
  - How an OS works
  - What an OS expects from the hardware (CPU) it is running on
  - The security properties an OS needs to enforce and how it does so
- Here we focus on **CPU** and **memory**
  - We'll see how the OS interfaces with devices (**I/O**) later

---
class: inverse, center, middle

# A (Very Brief) Description of How an OS Works

---
# Basic OS Principles

.left3col[
- A computer is made of **hardware**:
  - CPU, memory, and I/O (disk and network)
- Software runs on top of that hardware, and **the OS manipulates the hardware** directly
- **Applications** run on top of the OS
  - Can't let them access most of the hardware directly for safety/stability
]

.right3col[
  <div style="text-align:center"><img src="include/os-1.svg" width=350 /></div>
]
---
# Basic OS Principles (2)

.left3col[
- OS provide **standardised abstractions** for applications to use the hardware safely
  - E.g. processes and threads for CPU/memory, filesystem for storage, sockets for network, etc.
- These abstractions are accessed through a standard API: **system calls**
  - On Linux: `open`, `read`, `write`, `mmap`, etc.
]

.right3col[
  <div style="text-align:center"><img src="include/os-2.svg" width=350 /></div>
]

---
# Boot Time

Basic steps (ultra simplified):
1. Power on
2. Motherboard firmware (BIOS) performs basic hardware initialisation and then runs the bootloader
3. Bootloader (e.g. Grub) takes over
4. OS kernel is loaded by the bootloader, starts to run
5. OS initialises more hardware and itself
6. Once ready OS can run applications

---
name: cpu
# Execution Model on the CPU

- CPU: ALU + control logic + registers (amongst other things)
- **Instruction pointer** (AKA program counter): register pointing to the code to execute in memory
- Load/store instructions to read/write data from/to memory

---
template: cpu
<div style="text-align:center"><img src="include/cpu-state-1.svg" width=700 /></div>

---
template: cpu
<div style="text-align:center"><img src="include/cpu-state-2.svg" width=700 /></div>

---
template: cpu
<div style="text-align:center"><img src="include/cpu-state-3.svg" width=700 /></div>

---
template: cpu
<div style="text-align:center"><img src="include/cpu-state-4.svg" width=700 /></div>

---
template: cpu
<div style="text-align:center"><img src="include/cpu-state-5.svg" width=700 /></div>

---
template: cpu
<div style="text-align:center"><img src="include/cpu-state-6.svg" width=700 /></div>

---
# Execution Model on the CPU

- The content of the registers define the application's state on the CPU
- It can be saved and restored to/from memory e.g. for a context switch

---
# Kernel Invocation

When does the kernel get invoked, i.e. **when does the CPU starts executing kernel code?**

Only on 2 occasions:
- At boot time after the bootloader finishes to load the kernel
- At runtime when an **interrupt** is received by the processor.

There are 2 types of interrupts:
  - **Hardware interrupts** for I/O: a device sends an interrupt to the CPU
  - **Software exceptions** (e.g. division by zero): the CPU interrupts itself

---
name: interrupt
# Kernel Invocation

---
template:interrupt
<div style="text-align:center"><img src="include/interrupt-1.svg" width=700 /></div>

---
template: interrupt
<div style="text-align:center"><img src="include/interrupt-2.svg" width=700 /></div>

---
template: interrupt
<div style="text-align:center"><img src="include/interrupt-3.svg" width=700 /></div>

---
template: interrupt
<div style="text-align:center"><img src="include/interrupt-4.svg" width=700 /></div>

---
template: interrupt
<div style="text-align:center"><img src="include/interrupt-5.svg" width=700 /></div>

---
# Security

- **We cannot have an application read/write the memory of another application or of the kernel**

---
name: security
# Security

- OS sets up MMU to perform virtual to physical address mapping
- An app is tricked into thinking it has access to 100% of the memory
- It cannot address the memory belonging to other apps/the kernel

---
template: security
<div style="text-align:center"><img src="include/security-2.svg" width=650 /></div>

---
template: security
<div style="text-align:center"><img src="include/security-3.svg" width=650 /></div>

---
template: security
<div style="text-align:center"><img src="include/security-4.svg" width=650 /></div>

---
# System Calls

- **If the application cannot access kernel data/run kernel code for security reasons, how can it invoke OS services?**
--

- When invoking a system call, the application executes a special instruction that triggers an exception and the CPU starts running the kernel to manage the system call

.leftcol[
<div style="text-align:center"><img src="include/interrupt-6.svg" width=400 /></div>
]

.rightcol[
```asm
00000000004672b0 <__clock_gettime>:
#...
  4672f8:	mov    %r12,%rsi
  4672fb:	mov    %ebp,%edi
  4672fd:	mov    $0xe4,%eax
* 467302:	syscall 
# ...
```
]

---
# Privilege Modes

- **Some CPU instructions are privileged**, they should only be executed by the kernel:
  - Installing a new page table
  - Communicating with the hardware
  - Shutting down/resetting the CPU
  - Etc.
--

- **Privilege modes** ensure applications cannot invoke them.
- At any time the processor is in one of two modes:
  - **user mode** when applications run
  - **supervisor mode** when the kernel runs
--

- A **privileged instruction executed by the application in user mode triggers an exception** and traps to the kernel

---
# Privilege Modes

Privilege modes have various names according to the architecture, on x86 they are called **protection rings**

Rings 1 and 2 were dropped with x86-64, leaving ring 0 (supervisor mode) and ring 3 (user mode)

---
# Wrapping Up
- OS abstracts hardware from applications for ease and **security reasons**:
  - Applications cannot access each other's memory or the kernel's memory
  - Applications cannot execute privilege operations e.g. shutting down the computer, installing new memory mappings, etc.
- To achieve that the OS assumes it has **complete control over the hardware**, e.g. it can execute privileges instructions
- With virtualisation, **how can we run 2 OSes on the same hardware (same computer) without them stepping on each other's feet?**