Download Memory Management and Protection in Operating Systems: An Evolutionary Path and more Slides Computer Numerical Control in PDF only on Docsity!
Memory Management
Arvind Krishnamurthy
Spring 2004
Memory Management
To support multiprogramming, we need “Protection”
n How to implement an address space?
Physical memory Abstraction: virtual memory No protection Each program isolated from all others and from the OS
Limited size Illusion of infinite memory
Sharing visible to programs Transparent --- can’t tell if memory is shared Easy to share data between Controlled sharing of data programs
OS Evolutionary Path
n Uniprogramming without protection
n Multiprogramming without protection: linker-loader
n Multiprogrammed OS with protection:
n hardware-based approach n address translation (support of address space) n dual mode operation: kernel vs. user mode n software-based approach n type-safe languages n software fault isolation
Uniprogramming (no protection)
n Application runs at the same place in physical memory
n load application into low memory n load OS into high memory n application can address any physical memory location n application can corrupt OS and even the disk
Physical Memory
0x
Operating System
Application
0xFFFFFF
Linker-Loader example
int y; extern int z;
int foo() { int x;
bar(); y = 1; z = 1; } [foo.c]
int z;
void bar() { z = 99; }
main() { foo(); } [bar.c]
Link: Need to patch references to “bar”, “foo”, and “z”
Load: Need to relocate all addresses based on what programs are running
n Problem of linker-loader --- still no protection: bugs in any program can cause other programs to crash, even OS n Goal: how to support protection?
Incorporating Protection
n Goal of protection
n keep user programs from crashing/corrupting OS n keep user programs from crashing/corrupting each other
How is protection implemented?
n Almost all OS today use hardware-based approach
n address translation n dual mode operation: kernel vs. user mode
n Other approaches: software-based solutions
n type safe languages n software fault isolation
Address translation (1)
n Address space : state of an active program n Hardware translates every memory reference from virtual addresses to physical addresses n Software sets up and manages the mapping in the translation box
n Protection: there is no way for programs to talk about other program’s addresses
CPU
Translation Box
(MMU) (^) physical memory
virtual address
physical address
Data read or write
Why dual mode operation?
n If application can modify its own translation tables --- then
it can access all of physical memory --- protection is lost!
n Solution: use “dual-mode” operation
n when in the OS, can do anything (kernel-mode) n when in a user program, restricted to only touching that program’s memory (user-mode) HW can require CPU to be in kernel-mode to modify address translation table
n In Nachos (as well as most OS’s):
n OS runs in kernel mode (untranslated addresses) n User programs run in user mode (translated addresses)
n How does one switch between kernel and user modes?
Issues with system call
n Can the user program call any routine in the OS?
n No. Only the specific ones that the OS says are ok.
n How to pass arguments on a system call?
n via registers n write data into user memory, kernel copies into its memory except: user addresses --- translated kernel addresses --- untranslated
n main problem : addresses the kernel sees are not the same addresses as what the user sees
n What if user programs does a system call with bad
arguments? OS must check everything
User ‡ kernel: how to switch
n On system call, interrupt exception and the system
n sets processor status to kernel mode n changes execution stack to an OS kernel stack n saves current program counter n jumps to handler routine in OS kernel n handler saves previous state of any register it uses
n Context switches between programs:
n same as with threads, except n also save and restore pointer to translation table n to resume a program: reload registers, change PSW, and jump to old PC.
OS Structure
n How does Nachos’s structure fit into this model? n Nachos is the portable OS layer – it simulates the hardware and machine- dependent layer, and it simulates the execution of user programs running on top n Can still use debugger, printf, etc. n Can run normal UNIX programs concurrently with Nachos n Could run Nachos on real hardware by writing a machine-dependent layer
Application
Application library
Portable OS layer
Machine dependent layer
User mode
Kernel mode
