Protection: Kernel and Address Spaces

1. Protection: Kernel and Address Spaces • Goal of Protection • Keep user programs from crashing OS • Keep user programs from crashing each other

2. Requires Hardware Support • Early PCs offered none (ex: Intel 8088) • More modern architectures do • 2 primary types of support • Address translation • Dual mode operation: kernel vs. user mode

3. Address Translation • Address space: • Consists of code, data, files • Literally, all the addresses a program can touch. All the state that a program can affect or be affected by. • Restrict what a program can do by restricting what it can touch

4. Address Translation in Modern Architectures • Hardware translates every memory reference from virtual address to physical addresses; software sets up and manages the mapping in the translation box. Physical Memory Virtual Address Physical Address Memory Management Unit(MMU) CPU

5. Two Views of Memory • View from the CPU – what program sees, virtual memory • View from memory – physical memory • Translation box (MMU) converts between the two views

6. How does address translation help? • Completely encapsulate address space • Have only virtual addresses • MMU translate them to physical addresses • No way to know where others’ address space • Ex: suppose first line of code of OS is at physical address 0 – MMU won’t allow any translation to address 0 from user program Think of MMU’s translation as table lookup

7. How to manage MMU? • OS is allowed to change MMU tables • What if user could modify them? • Could get to all of physical memory • Could crash OS, or other users • Need to avoid this • Again hardware helps: dual mode operation

8. Dual Mode Operation • Processor Status Word (PSW) has mode bit • A special purpose register • If 0, kernel mode; if 1, user mode • In kernel mode, can do anything (OS has control) • In user mode, can only do certain things • Cannot modify MMU • Cannot turn interrupts off and on • Cannot read directly from disk • Cannot halt machine How to share CPU between kernel and users?

9. From Kernel to User • Suppose kernel wants to run user program • Create a new thread to: • Allocate and initialize address space • Read program off disk into memory • Initialize translation tables (MMU) and registers • Set hardware register to correct translation tables • There are many, need correct user’s • Change mode bit to 1 • Jump to first line of code

10. From User to Kernel • Involuntary • Hardware interrupt • Program exception • Bus error • Segmentation fault • Page fault • Voluntary • System call – like doing procedure call to kernel • On system call, interrupt, or exception: hardware atomically: • Save state of user program (registers, PC, etc.) • Sets processor states to kernel and jump in

11. System Calls • System call – special instruction to jump to a specific operating system handler. • Can the user program call any routine in the OS? • No. Just specific ones the OS says is ok. Always start running handler at same place, otherwise, problems! • How does OS know that system call arguments are as expected? • It can’t – kernel has to check all arguments.

12. System Calls • User needs to get back to into kernel • Examples: • Execute a new program (in new address space) • Wait for another program to complete • Do file I/O • Communicate with other address spaces • How does the system call pass arguments? • Use registers • Write into user memory, kernel copies into its memory

13. Communication between address spaces • Share a region of memory • Inter-process communication, communication has to go through kernel via system calls • Byte stream producer/consumer. Ex: communicate through pipes connecting stdin/stdout • Message passing (send/receive) • File system (read and write files). File system is shared state!

14. Communication Models Message Passing Shared Memory

15. Memory Management • Modern OS’s allow multiple address spaces in memory • Require sharing physical memory • Many different techniques exist • Depends on hardware and on OS design

16. No Hardware Support • Might still have uni- or multi- programming • One program at a time in physical memory • MS-DOS • Multiple program in memory • Several fixed partitions • Must deal with relocation • Address must be modified based on partition • Use linker-loader to place programs in memory • Linker identifies addresses to be modified, loader actually modifies those addresses

17. Swapping • Move entire thread + address space to disk • Expensive • Not used in many systems • Some UNIX versions swap a process when too many in physical memory • MS-Windows allows “concurrent executions” via swapping

18. Single Partition/Base + Bounds • Goal: user program can’t crash OS • Still one process in memory at a time • MMU consists of 2 registers • User addresses added to base register • Final address compared to limit register • If greater than limit, trap to OS (address error) • Base and Bounds protect OS

19. Multiple Partitions/Base+Bounds • Now multiple processes in memory at once • Different base and limit for each process • When OS changes between address space: • Modify base and bounds for new address space • Privileged instructions • Note that every memory access is slower

20. Multiple Partitions (cont.) • Have some number of fixed-size partitions • Limits degree of multiprogramming • When process done, have unused “hole” • Must manage memory (linked list, bitmap, etc.) • First fit – allocate first hole • Best fit – allocate smallest hole • Worst fit – allocate largest hole

21. Fragmentation • External • Have enough memory, but not contiguous • Can’t satisfy requests • Ex: first fit wastes 1/3 of memory on average • Internal • Don’t manage small holes • Waste them instead

22. Base/Bounds with Multiprogramming: Evaluation • Pros: • Simple and fast • Cons: • How to share between programs? • Ex: would like to share netscape code • How to allow address space to grow? • Ex: have to start stack and heap somewhere; at some point stack might “bump” into heap! • How to allocate memory simply?