1 / 60

CompSci 510: Graduate OS

CompSci 510: Graduate OS. Landon Cox January 10, 2018. About me. Background BS in Math, CS: Duke ‘99 PhD in CSE: Michigan ‘05 Research interests OS and distributed systems Mobile computing Privacy and security. About CompSci 510. CompSci 510 is about operating-systems research

sancheze
Download Presentation

CompSci 510: Graduate OS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. About me • Background • 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 Files, web Virtual Memory Threads Disk , NIC Page Tables Atomic Test/Set OS 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. 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 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 • Email 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

  21. https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-discovery/https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-discovery/

  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 Physical address Virtual address Base and bounds Segmentation Paging

  27. Multi-level page table 0 1 … ? 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 CPU Page table PTBR Page table base register (PTBR) OS

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

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

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

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

  33. Accessing virtual memory User process Physical memory Access virtual address Physical pages CPU Page table 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 CPU Page table PTBR If not OK, trap to OS OS

  35. Accessing virtual memory User process Physical memory Access virtual address Physical pages CPU Page table 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 CPU Page table 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 CPU Page table 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 CPU Page table PTBR If not OK, trap to OS OS If not resident, load non-resident page

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

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

  41. Multi-level page table 0 1 … ? 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 (0xc0000000) 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? • This requires hardware support • CPU supports different modes, kernel and user • Mode is indicated by a hardware register • Mode bit

  47. Protection recap 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 • 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

More Related