1. CompSci 510: Graduate OS
Landon Cox
January 10, 2018

2. About me Background Research interests BS in Math, CS: Duke ‘99
PhD in CSE: Michigan ‘05
Research interests
OS and distributed systems
Mobile computing
Privacy and security

3. About CompSci 510 CompSci 510 is about operating-systems research
You will read a lot of old and new papers
You will perform a semester-long research project
What CompSci 510 is not about
Learning basic operating systems concepts
Will do some review, but you should already know this material
Who should take it?
Graduate students and undergrads who enjoyed CompSci 310

4. Two roles of the OS

5. OS as illusionist

6. Abstractions, hardware reality
Applications
Programs
Threads
Virtual
Memory
Files,
web OS
Atomic
Test/Set
Page
Tables
Disk ,
NIC
Hardware
Hardware

7. OS as government

8. Main government functions
Resource manager (who gets what and when)
Lock acquisition
Processes
Disk requests
Page eviction
Isolation and security (law and order)
Access control
Kernel bit
Authentication

9. Fair, efficient allocation
Two roles of the OS
Abstractions
Government
Modularity
Simplicity
Hide messy reality
Law and order
Fair, efficient allocation
Source of trust
Goals for each role?

10. Two roles of the OS Abstractions Government Modularity Simplicity
Hide messy reality
Law and order
Fair, efficient allocation
Source of trust
How does OS enforce modularity?

11. Two roles of the OS Abstractions Government Modularity Simplicity
Hide messy reality
Law and order
Fair, efficient allocation
Source of trust
How does OS ensure fair allocation?

12. Two roles of the OS Abstractions Government Modularity Simplicity
Hide messy reality
Law and order
Fair, efficient allocation
Source of trust
What is the basis for trust?
Why do we trust the government?

13. Key questions for semester
What are the right abstractions?
How should we enforce modularity?
How do we ensure fair, efficient resource allocation?
Is there a reasonable basis for trust?
We will read a lot of papers this semester
Useful to think about them in terms of these questions
Sometimes goals are in tension (e.g., modularity vs. efficiency)
Good papers help us understand the trade-offs

14. Course administration
Syllabus is online
Reading list/schedule is subject to change
In general, one or two papers per lecture
Grade composition
Paper summaries (5%)
Programming projects (20%)
Research project (25%)
In-class midterm (25%)
In-class final exam (25%)

15. Paper summaries Post summaries to Piazza Summaries must include
Summaries will be available to all
Due before class
Summaries must include
Two positives
Two negatives
Two questions

16. Programming Projects Done in groups of two or three
me your groups by January 18
Two small programming projects
Virtual memory (50%)
Building a shell (50%)

17. Research Projects Done in groups of two or three Four phases
Form groups (due after first prog project)
Project proposal (5% of project grade)
Status report (20% of pg)
Final report and demo (75% of pg)

18. Exams Both will be closed-note and in-class
Will cover topics covered to that point
Often will ask about composing systems
“How would SimOS run on top of LFS?”
Requires a clear understanding of both

19. Syllabus: project collaboration
Okay between groups
Programming syntax, course concepts
“What does this part of the project specification mean?”
Not okay between groups
Design/writing of another’s program
Includes prior class solutions and Piazza
“How do I do this part of the handout?”
Don’t post details of your solution to Piazza
If in doubt, ask me

20. Meltdown and Spectre

22. Understanding these attacks
Building blocks
Address spaces
Speculative execution
Side channels
Attack targets
Kernel memory
Web browser sandboxes (e.g., javascript)

23. Understanding these attacks
Building blocks
Address spaces
Speculative execution
Side channels
Attack targets
Kernel memory
Web browser sandboxes (e.g., javascript)

24. Hardware, OS interfaces
Applications
Job 1
Job 2
Job 3
CPU, Mem
CPU, Mem
CPU, Mem OS
Memory
CPU
Hardware

25. Illusions of the address space
Address independence
Can use same numeric address in two processes
Each process has its own version of “address 4”
Each “address 4” refers to different data items
Protection
One process cannot corrupt another’s data
Virtual memory
Address space can be larger than physical memory

26. Dynamic address translation
User process
Translator
(MMU)
Physical
memory
Virtual
address
Physical
address
Base and bounds
Segmentation
Paging

27. Multi-level page table1 …
1023 ?
Level 1
NULL
NULL
Level 2
0: PhysPage, Res, Prot
0: PhysPage, Res, Prot
1: PhysPage, Res, Prot
1: PhysPage, Res, Prot … … ?
1023: PhysPage, Res, Prot ?
1023: PhysPage, Res, Prot

28. Accessing virtual memory
User process
Physical memory
Page table
CPU
PTBR
Page table base register (PTBR) OS

29. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR OS

30. Accessing virtual memory
User process
Physical memory
Access virtual address
Determine if access is allowed
Physical pages
Page table
CPU
PTBR OS

31. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If OK, retrieve data,
execute instruction OS

32. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS OS

33. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS
Determine if access is valid OS

34. Accessing virtual memory
User process
If not valid,
kill process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS OS

35. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS
If valid, determine if resident OS

36. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS
If resident,
update protections OS

37. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS
If resident,
update protections,
retry faulting instruction OS

38. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS
If not resident,
load non-resident page OS

39. Accessing virtual memory
User process
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS
If not resident,
load non-resident page,
update page table OS

40. Accessing virtual memory
User process
Retry faulting instruction
Physical memory
Access virtual address
Physical pages
Page table
CPU
PTBR
If not OK, trap to OS
If not resident,
load non-resident page,
update page table OS

41. Multi-level page table1 …
1023 ?
Level 1
NULL
NULL
Level 2
0: PhysPage, Res, Prot
0: PhysPage, Res, Prot
1: PhysPage, Res, Prot
1: PhysPage, Res, Prot … … ?
1023: PhysPage, Res, Prot ?
1023: PhysPage, Res, Prot

42. User/kernel translation data
4GB
Kernel data
(same for all page tables)
3GB (0xc )
User data
(different for every process)
0GB
Virtual memory

43. Where to store translation data?
Point MMU to physical address where it resides
On x86, PTBR (aka CR3 register) refers to physical memory
To change page table, update PTBR
Data structure maintained in kernel virtual address space
Kernel instructions still reference virtual addresses
How does kernel manipulate translation data that is itself translated?
Page tables reside in kernel’s virtual memory
Kernel’s translation data always in physical memory (pinned)
Does anything else need to be pinned (and why)?
Kernel’s page fault handler code also has to be pinned.
Fault handling instructions cannot page themselves in

44. Where to store translation data?
How does kernel access data in user’s address space?
If for currently loaded process, access using current page table
If for another process, have to change page table

45. Kernel vs. user mode Who sets up the data used by the MMU?
Can’t be the user process
Otherwise could access anything
Only kernel is allowed to modify any memory
Processor must know to allow kernel
To update the translator (e.g., set PTBR)
To execute privileged instructions (halt, do I/O)

46. Kernel vs. user mode How does machine know kernel is running? Mode bit
This requires hardware support
CPU supports different modes, kernel and user
Mode is indicated by a hardware register
Mode bit

47. Protection recap All memory accesses go through a translator
GBs
of protected data
All memory accesses go through a translator
Who can modify translator’s data?
Only kernel can modify translator’s data
How do we know if kernel is running?
Mode bit indicates if kernel is running
Who can modify the mode bit?
One bit
of protected data
Making progress: the amount of protected data is down to a bit

48. Protecting the mode bit
Can kernel change the mode bit?
Yes. Kernel is completely trusted.
Can user process change the mode bit?
Not directly
User programs need to invoke the kernel
Must be able to initiate a change

49. When to transition from user to kernel?
Exceptions (interrupts, traps)
Access something out of your valid address space
(e.g., segmentation fault)
Disk I/O finishes, causes interrupt
Timer pre-emption, causes interrupt
Page faults
System calls
Similar in purpose to a function call
Kernel as software library

50. Example system calls Process management Signals Memory management
Fork/exec (start a new process), exit, getpid
Signals
Kill (send a signal), sigaction (set up handler)
Memory management
Brk (extend the valid address space), mmap
File I/O
Open, close, read, write
Network I/O
Accept, send, receive
System management
Reboot

51. System call implementation
Syscalls are like functions, but different
Implemented by special instruction
Software trap
syscall
Execution of syscall traps to kernel
Processor safely transfers control to kernel
Hardware invokes kernel’s syscall trap handler

52. System call implementation
Libc wraps systems calls
C++/Java make calls into libc

53. Tracing through “cin >> a;”
C++: cin >> a
Java: in.read()
C: read ()
libc: syscall(SYS_read,filenum,offset,numbytes)
Processor: kernel’s syscall handler
Crucial
step
kernel: sys_read
kernel: // perform I/O

54. Kernel trap details Hardware must atomically
Set processor mode bit to “kernel”
Save current registers (SP, PC, general purpose)
Change execution stack to kernel (SP)
Jump to exception handler in kernel (PC)

55. Kernel trap details User process can initiate mode switch
But only transfers control in limited way
(i.e., to predefined kernel code)
How does processor know where to jump?
Stored in hardware “interrupt vector table”
Who can update the interrupt vector table?
Kernel does this at startup
Code that runs first gets control of machine

56. Syscall arguments, return values
For args passed in memory, in which address space do they reside?
User (programs can’t access kernel’s address space)
Linux passes parameters via registers
Before syscall
Push ebp, edx, ecx vals onto user stack
Copy esp (stack pointer) into ebp
Each process has kernel stack
CPU knows kernel stack via “Task Segment State”
CPU sets esp using TSS
Kernel finds user stack in ebp register

57. Tracing through read()
C: read (int fd, void *buf, size_t size)
libc: push fd, buf, size onto user’s stack
Note: pointer!
kernel: sys_read () {
verify fd is an open file
verify [buf – buf+size) valid, writable
read file from data (e.g., disk)
find physical location of buf
copy data to buf’s physical location }
Verify
arguments!

58. Hidden channels Get system to communicate in unintended ways
Example: tenex (supposedly secure OS)
Created a team to break in
Team had all passwords within 48 hours … oops.
Goal: require 256^8 tries to see if password is right
Password checker
for (i=0; i<8; i++) {
if (input[i] != password[i]) {
break; }

59. Hidden channels: tenex
Password checker
for (i=0; i<8; i++) {
if (input[i] != password[i]) {
break; }
How to break? (hint: can detect vm faults)
Specially arrange the input’s layout in memory
Force a page fault if second character is read
If you get a fault, the first character was right
Do again for third, fourth, … eighth character
Can check the password in 256*8 tries

60. For next time
Read the Meltdown and Spectre papers