- Questions on the Challenge?
Start with Christo's slides
Arch and Kernels Slides
Stop at "A Simple OS Example"
Modern PC diagram
- Multi-core processor
- Dual channel RAM with two seperate dedicated busses
- PCI-e direct to each device
- Stuff like USB comes off a PCI-e lane.
- Legacy FSB with maybe a serial and PS/2 keyboard port.
Modern PC Boot
Early Boot: Old Plan
- Processor starts @ BIOS
- BIOS selects boot disk
- Reads partition table, selects boot partition
- Reads MBR, loads 1st-stage bootloader
- 1st stage loads second stage
- Second stage selects and loads kernel
- OS Kernel is in control
Early Boot: Modern Systems
- Management Engine starts processor
- Processor starts @ UEFI
- UEFI selects boot device or boot OS
- Loads 1st stage bootloader, verifies signature
- Transfers control to 1st stage.
- 1st stage loads second stage.
- 2nd stage loads kernel, after optionally verifying signature
- OS Kernel is in control
- Basically all modern computers have a sketchy second processor that runs
before the main processor boots and has full access to the hardware.
- Intel ME, AMD PSP, Raspberry Pi GPU
- These processors are intended to enable "enterprise" remote administration
regardless of installed software or even operating system.
- The Intel implementation has had some pretty bad security issues.
- After a major security issue last year, researchers discovered a way to
disable the Intel ME on some machines using a mechanism that was later
confirmed to have been required by the NSA for their machines.
UEFI Secure Boot
- UEFI fixes some major issues with BIOS
- Disk size limit
- Partition count limit
- Being 30 years old
- But adds a sketchy new feature: Secure Boot
- This feature had existed previously on phones, where it’s called a "locked
- Computers with this feature can only boot signed operating system code. Other
operating system code won’t load.
Signed by who?
- Cryptographic keys that can be used to verify boot software are loaded by the
- On phones, that’s generally manufacturer keys.
- On machines sold with Windows, that’s generally just a key from Microsoft.
- On Chromebooks, it’s a key from Google.
- Some systems allow the user to load their own keys and thus sign their own
- Some viruses have operated by overwriting the boot loader. Secure boot
prevents such infected systems from booting up at all.
- Other malware like keyloggers or remote access trojans like to run early in
the boot process. This similarly prevents them from working.
- Allows guarantees about all the software running on a system if the OS wants
to enforce it - can require package signatures, iOS style.
- Allows systems to make guarantees like "no screen capture software is running
while playing a video", for "content protection".
- The practicality of resisting attacks by someone with physical access to a
computer is limited. They could always do things like installing a hardware
- The person most likely to have physical access to a device and the ability to
attempt an OS install is the owner.
- Being "secure against the owner" so you can prevent them from installing
their choice of operating system sounds like an anti-feature to me.
This produces an amusing result: The bootloader on many Linux install images is
signed by Microsoft.
The OS Kernel
- Runs on boot and stays running while system is on
- Provides syscalls, which means it must manage:
- Virtual memory
- File systems and file I/O
- Network I/O
- Other hardware access
Consider a single-core processor.
- Usually we want a user program running.
- We transfer control from the user program to the kernel in two cases:
- The kernel runs with extra priviledges compared to normal programs.
- The kernel can access all of memory - user programs can't access restricted
- The kernel can execute all instructions - user programs can't access
- We say that the kernel runs in "ring 0", while user programs run in "ring 3".
This is determined by a bit in the page table. The priviledge level of code
being executed depends on how this flag is set in the virtual memory page the
code was loaded from.
- Logically, syscalls are like function calls.
- Mechanically, they work a little differently - syscalls are identified
by a number indexing into a syscall table (array of function pointers)
in kernel memory.
- When a syscall occurs, the kernel looks up the syscall # (%rax) in this
table, and then invokes the function pointer it finds.
- Hardware events
- Interrupts can also be triggered from software.
- Press a key on the keyboard.
- That sends a signal down a physical wire - say interrupt line #10 - into the
- There's an interrupt table (an array of function pointers) that the kernel has
- The processor stops the currently running program, switches to kernel mode,
and runs the function in interrupt table slot #10.
- That function will use I/O ports or device-mapped memory to read the keypress
from the keyboard and send it on to the terminal driver (or GUI, or whoever
- Once the interrupt is done, the user program is resumed - without even knowing
that it stopped.
This is important for programming. If you're writing a normal program it will
be randomly stopped for interrupts. Usually instructions happen nanoseconds
apart, but you'll occasionally see long gaps. If another process gets scheduled,
the gap between your instructions may be 8 milliseconds or more.
Finish the Slides
Arch and Kernels Slides