lec4.ppt system calls explained in detail

System Calls & Libraries
Vivek Pai
Lecture 4, COS318
Sep 25, 2001

System Calls & Libraries 2
Gedankundmathematics
Recall the pointer verification case for fread( )
 Can you speed up the checking process?
 What’s the best you could achieve? O(n)?
O(logn)? O(1)?
 What happens if you have >32 bits?
 Aside: # atoms in universe = 1080, or 2256
 Does this provide any other benefits?

Mechanics
 Is the project workable?
 Has everyone started?
 Barring major problems, due Tuesday
midnight
 Readings updated

Protection Issues
 I/O protection
 Prevent users from performing illegal I/Os
 Memory protection
 Prevent users from modifying kernel code
and data structures
 CPU protection
 Prevent a user from using the CPU for too
long

Protection Is Not Safety/Security
 Protection is a prerequisite
 Safety can be separation of concerns
 Security related to overall design
Examples?
 Bad pointer access causing seg fault
 Sniffing cleartext passwords on the wire

Support in Modern Processors:
User  Kernel
User mode
Regular instructions
Access user-mode memory
Kernel (privileged) mode
Regular instructions
Access user-mode memory
An interrupt or exception (INT)
A special instruction (IRET)

Why a Privileged Mode?
 Special Instructions
 Mapping, TLB, etc
 Device registers
 I/O channels, etc.
 Mode Bits
 Processor features
 Device access

x86 Protection Rings
Level 0
Level 1
Level 2
Level 3
Operating system
kernel
Operating system
services
Applications
Privileged instructions
Can be executed only
When current privileged
Level (CPR) is 0

Other Design Approaches
 “Capabilities”
 Fine-grained access control
 Crypto-like tokens
 Microkernels
 OS services in user space
 Small core “hypervisor”

Monolithic
 All kernel routines
are together
 A system call
interface
 Examples:
 Linux
 Most Unix OS
 NT
Kernel
many many things
entry
User
program
User
program

Monolithic Pros and Cons
Pros
 Relatively few crossings
 Shared kernel address space
 Performance
Cons
 Flexibility
 Stability
 Experimentation

Layered Structure
 Hiding information at
each layer
 Develop a layer at a
time
 Examples
 THE (6 layers)
 MS-DOS (4 layers) Hardware
Level 1
Level 2
Level N
.
.
.

Layering Pros and Cons
Pros
 Separation of concerns
 Simplicity / elegance
Cons
 Boundary crossings
 Performance?

Microkernel
 Micro-kernel is “micro”
 Services are
implemented as regular
process
 Micro-kernel get
services on behalf of
users by messaging with
the service processes
 Examples: Taos, Mach,
L4
m-kernel
entry
User
program
Services

Microkernel Pros and Cons
Pros
 Easier to develop services
 Fault isolation
 Customization
 Smaller kernel => easier to optimize
Cons
 Lots of boundary crossings
 Really poor performance

Virtual Machine
 Virtual machine monitor
 provide multiple virtual
“real” hardware
 run different OS codes
 Example
 IBM VM/370
 virtual 8086 mode
 Java
 VMWare Bare hardware
Small kernel
VM1 VMn
. . .
OS1 OSn
user user

Hardware Support
 What is the minimal support?
 Can virtual machine be protected without such
support?
 Hint: what is a Turing machine?

System Call Mechanism
Kernel in
protected memory
entry
 User code can be arbitrary
 User code cannot modify
kernel memory
 Makes a system call with
parameters
 The call mechanism switches
code to kernel mode
 Execute system call
 Return with results
User
program
User
program

Interrupt and Exceptions
 Interrupt Sources
 Hardware (by external devices)
 Software: INT n
 Exceptions
 Program error: faults, traps, and aborts
 Software generated: INT 3
 Machine-check exceptions
 See Intel document chapter 5, volume 3 for
details

Interrupt and Exceptions (1)
Vector # Mnemonic Description Type
0 #DE Divide error (by zero) Fault
1 #DB Debug Fault/trap
2 NMI interrupt Interrupt
3 #BP Breakpoint Trap
4 #OF Overflow Trap
5 #BR BOUND range exceeded Trap
6 #UD Invalid opcode Fault
7 #NM Device not available Fault
8 #DF Double fault Abort
9 Coprocessor segment overrun Fault
10 #TS Invalid TSS

Interrupt and Exceptions (2)
Vector # Mnemonic Description Type
11 #NP Segment not present Fault
12 #SS Stack-segment fault Fault
13 #GP General protection Fault
14 #PF Page fault Fault
15 Reserved Fault
16 #MF Floating-point error (math fault) Fault
17 #AC Alignment check Fault
18 #MC Machine check Abort
19-31 Reserved
32-255 User defined Interrupt

System Calls
 Interface between a process and the
operating system kernel
 Categories
 Process management
 Memory management
 File management
 Device management
 Communication

OS Kernel: Trap Handler
HW Device
Interrupt
HW exceptions
SW exceptions
System Service Call
Virtual address
exceptions
HW implementation of the boundary
System
service
dispatcher
System
services
Interrupt
service
routines
Exception
dispatcher
Exception
handlers
VM manager’s
pager
Sys_call_table

Passing Parameters
 Affects and depends on
 Architecture
 Compiler
 OS
 Different choices for different purposes

Passing Parameters - Registers
Place parameters in registers
 # of registers
 # of usable registers
 # of parameters in system call
 Spill/fill code in compiler
Really fast

Passing Parameters - Vector
Register holds vector address
 Single register
 Vector in user’s memory
 Nothing horrible, just not common

Passing Parameters - Stack
Place parameters on stack
 Similar to vector approach
 Stack already exists
 Gets copied anyway
frame
frame
Top

Library Stubs for System Calls
 Use read( fd, buf, size) as
an 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
stack
Registers
User
memory
Kernel
stack
Registers
Kernel
memory
Linux: 80
NT: 2E

System Call Entry Point
User
stack
Registers
User
memory
Kernel
stack
Registers
Kernel
memory
 Assume passing parameters
in registers
EntryPoint:
switch to kernel stack
save context
check R0
call the real code pointed by
R0
restore context
switch to user stack
iret (change to user mode and
return)

Design & Performance Issues
 Can user code lie?
 One result register – large results?
 Parameters in user memory
 Multiprocessors

General Design Aesthetics
 Simplicity, obviousness
 Generality – same call handles many cases
 Composition / decomposition
But:
 Expressiveness
 Performance

Separation Of Concerns
Memory management
 Kernel allocates “pages” – hw protection
 Programs use malloc( ) – fine grained
 Kernel doesn’t care about small allocs
 Allocates pages to library
 Library handles malloc/free

Library Benefits
 Call overhead
 Chains of alloc/free don’t go to kernel
 Flexibility – easy to change policy
 Fragmentation
 Coalescing, free list management
 Easier to program

Feedback To The Program
 System calls, libraries are program to OS
 What about other direction?
 Various exceptional conditions
 General information, like screen resize
 When would this occur?
Answer: signals

lec4.ppt system calls explained in detail

More Related Content

Similar to lec4.ppt system calls explained in detail

Recently uploaded

lec4.ppt system calls explained in detail