System Call and OS Structures

7/30/2019 System Call and OS Structures

1/34

System Calls & Libraries

Vivek PaiLecture 4, COS318

Sep 25, 2001


2/34


3/34

System Calls & Libraries 3

Mechanics Is the project workable?

Has everyone started?

Barring major problems, due Tuesday

midnight

Readings updated


4/34


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


5/34


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


6/34


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)


7/34System Calls & Libraries 7

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 systemkernel

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 callinterface

Examples:

Linux Most Unix OS

NT

Kernelmany many things

entry

User

program

User

program



Monolithic Pros and ConsPros

Relatively few crossings

Shared kernel address space Performance

Cons

Flexibility

Stability

Experimentation



Layered Structure Hiding information at

each layer

Develop a layer at atime

Examples

THE (6 layers) MS-DOS (4 layers)

Hardware

Level 1

Level 2

Level N.

..



Layering Pros and ConsPros

Separation of concerns

Simplicity / elegance

Cons

Boundary crossings Performance?



Microkernel Micro-kernel is micro

Services are

implemented as regularprocess

Micro-kernel getservices on behalf of

users by messaging withthe service processes

Examples: Taos, Mach,L4

m-kernel

entry

User

programServices



Microkernel Pros and ConsPros

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 inprotected memory

entry

User code can be arbitrary

User code cannot modifykernel memory

Makes a system call withparameters

The call mechanism switchescode to kernel mode

Execute system call

Return with results

User

program

User

program



Interrupt and Exceptions Interrupt Sources

Hardware (by external devices)

Software: INTn 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 Fault14 #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 theoperating 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

dispatcherSystem

services

Interrupt

service

routines

Exception

dispatcher Exception

handlers

VM managers

pager

Sys_call_table


24/34


Passing Parameters Affects and depends on

Architecture

Compiler

OS

Different choices for different purposes


25/34


Passing Parameters - RegistersPlace parameters in registers

# of registers

# of usable registers

# of parameters in system call

Spill/fill code in compiler

Really fast


26/34


Passing Parameters - VectorRegister holds vector address

Single register

Vector in users memory

Nothing horrible, just not common


27/34


Passing Parameters - StackPlace parameters on stack

Similar to vector approach

Stack already exists

Gets copied anyway

frame

frame

Top


28/34


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 $0x80move result to Rresult

}

User

stack

Registers

User

memory

Kernel

stack

Registers

Kernelmemory

Linux: 80

NT: 2E


29/34


System Call Entry Point

User

stack

Registers

User

memory

Kernel

stack

Registers

Kernelmemory

Assume passing parameters

in registers

EntryPoint:

switch to kernel stack

save context

check R0

call the real code pointed by

R0

restore contextswitch to user stack

iret (change to user mode and

return)


30/34


Design & Performance Issues Can user code lie?

One result registerlarge results?

Parameters in user memory

Multiprocessors


31/34


General Design Aesthetics Simplicity, obviousness

Generalitysame call handles many cases

Composition / decomposition

But:

Expressiveness

Performance


32/34


Separation Of ConcernsMemory management

Kernel allocates pages hw protection

Programs use malloc( )fine grained

Kernel doesnt care about small allocs

Allocates pages to library Library handles malloc/free


33/34


Library Benefits Call overhead

Chains of alloc/free dont go to kernel

Flexibilityeasy to change policy

Fragmentation

Coalescing, free list management

Easier to program


34/34

34

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

Documents

System Call and OS Structures