COS 318: Operating Systems OS Structures and System Calls
COS 318: Operating Systems OS Structures and System Calls
Outline
! ! !
Protection Issues
!
CPU
" "
Kernel has the ability to take CPU away from users to prevent a user from using the CPU forever Users should not have such an ability Prevent a user from accessing others data Prevent users from modifying kernel code and data structures Prevent users from performing illegal I/Os
Memory
" "
I/O
"
Kernel (privileged) mode Regular instructions Privileged instructions Access user memory Access kernel memory
Memory address mapping Flush or invalidate data cache Invalidate TLB entries Load and read system registers Change processor modes from kernel to user Change the voltage and frequency of processor Halt a processor Reset a processor Perform I/O operations
Outline
! ! !
Monolithic
!
All kernel routines are together, any can call any A system call interface (main program, sys calls, utility funcs) Examples:
"
User program
sy sc al l
User program
a sc sy ll
Linux, BSD Unix, Windows Shared kernel space Good performance No information hiding Inflexible Chaotic Difficult to understand How many bugs in 5 million lines of code?
Pros
" "
Cons
" " " " "
Layered Structure
! ! !
Level N constructed on top of N-1 Hiding information at each layer E.g. level 1 is processor allocation, level 1 memory management, level 2 comm, level 3 I/O, etc. Examples
" "
THE System (6 layers) MS-DOS (4 layers) Layered abstraction Separation of concerns, elegance Protection, boundary crossings Performance
Pros
" "
Cons
" "
Microkernel
! !
! !
Put less in kernel mode: only small part of OS; reduce kernel bugs Services are regular processes; one file system crashing doesnt crash full system; cant corrupt kernel memory !-kernel gets svcs on behalf of users by messaging with service processes Examples: " Mach, Taos, L4, OS-X Pros? " Flexibility " Fault isolation and reliability (used in avionics and military apps) Cons? " Inefficient (boundary crossings) " Insufficient protection " Inconvenient to share data between kernel and services
User program
sy sc
OS Services
al l
entry !-kernel
10
Virtual Machine
!
Separate out multiprogramming from abstraction; VMM provides former Virtual machine monitor
" " "
Apps
Virtualize hardware, but expose it as multiple instances of raw hw Run several OSes, one on each set Examples IBM VM/370 Java VM VMWare, Xen
...
OSk VMk
Raw Hardware
11
Win Vista
Linux Apps
VMM
Linux
Outline
! ! !
13
Assumptions
" "
User code can be arbitrary User code cannot modify kernel memory User code makes a system call with parameters The call mechanism switches code to kernel mode Execute system call Return with results (Like a procedure call, just crosses kernel boundary)
Design Issues
" " " " "
User program
sy sc al l
User program
a sc sy ll
14
System Calls
!
Interface between an application and the operating system kernel Process management Memory management File management Device management Communication
Categories
" " " " "
15
Exception handlers
Passing Parameters
!
Pass by registers
" " " "
# of registers # of usable registers # of parameters in system call Spill/fill code in compiler Single register for starting address Vector in users memory Similar to the memory vector Procedure call convention
17
Pass by stack
" "
Example:
int read( int fd, char * buf, int size) { move fd, buf, size to R1, R2, R3 move READ to R0 int $0x80 move result to Rresult }
User program
In t$ ire 0x 80 t
Linux: 80 NT: 2E
18
EntryPoint: switch to kernel stack save context check R0 call the real code pointed by R0 place result in Rresult restore context switch to user stack iret (change to user mode and return) (Assume passing parameters in registers)
User stack
Kernel stack
Kernel memory
19
Design Issues
!
System calls
" " " "
There is one result register; what about more results? How do we pass errors back to the caller? Can user code lie? How would you perform QA on system calls? What should be system calls? What should be library calls?
20
Allocates pages with hardware protection Allocates a big chunk (many pages) to library Does not care about small allocs Provides malloc/free for allocation and deallocation Application use these calls to manage memory at fine granularity When reaching the end, library asks the kernel for more
Library
" " "
21
Applications view system calls and library calls as procedure calls What about OS to apps?
" "
Application
Operating System
22
Interrupt Sources
" "
Hardware (by external devices) Software: INT n Program error: faults, traps, and aborts Software generated: INT 3 Machine-check exceptions
Exceptions
" " "
23
Type Fault Fault/trap Interrupt Trap Trap Trap Fault Fault Abort Fault
Summary
!
Protection mechanism
" "
Architecture support: two modes Software traps (exceptions) Monolithic, layered, microkernel and virtual machine Implementation Design issues Tradeoffs with library calls
OS structures
"
System calls
" " "
26