CS 414 Review - PowerPoint PPT Presentation

About This Presentation
Title:

CS 414 Review

Description:

CS 414 Review – PowerPoint PPT presentation

Number of Views:176
Avg rating:3.0/5.0
Slides: 102
Provided by: Ranv70
Category:
Tags: check | matrix | parity | review

less

Transcript and Presenter's Notes

Title: CS 414 Review


1
CS 414 Review
2
Operating System Definition
Definition An Operating System (OS) provides a
virtual machine on top of the real hardware,
whose interface is more convenient than the raw
hardware interface.
Applications
OS interface
Operating System
Physical machine interface
Hardware
Advantages Easy to use, simpler to code, more
reliable, more secure, You can say I want to
write XYZ into file ABC
3
What is in an OS?
Quake
Sql Server
Applications
Windowing graphics
Shells
System Utils
OS Interface
Naming
Windowing Gfx
Operating System Services
Virtual Memory
Networking
Access Control
Generic I/O
File System
Process Management
Memory Management
Device Drivers
Physical m/c Intf
Interrupts, Cache, Physical Memory, TLB, Hardware
Devices
Logical OS Structure
4
Crossing Protection Boundaries
  • User calls OS procedure for privileged
    operations
  • Calling a kernel mode service from user mode
    program
  • Using System Calls
  • System Calls switches execution to kernel mode

User Mode Mode bit 1
Resume process
User process
System Call
Trap Mode bit 0
Kernel Mode Mode bit 0
Return Mode bit 1
Save Callers state
Execute system call
Restore state
5
What is a process?
  • The unit of execution
  • The unit of scheduling
  • Thread of execution address space
  • Is a program in execution
  • Sequential, instruction-at-a-time execution of a
    program.
  • The same as job or task or sequential
    process

6
Process State Transitions
interrupt
New
Exit
admitted
done
Ready
Running
dispatch
I/O or event completion
I/O or event wait
Waiting
  • Processes hop across states as a result of
  • Actions they perform, e.g. system calls
  • Actions performed by OS, e.g. rescheduling
  • External actions, e.g. I/O

7
Context Switch
  • For a running process
  • All registers are loaded in CPU and modified
  • E.g. Program Counter, Stack Pointer, General
    Purpose Registers
  • When process relinquishes the CPU, the OS
  • Saves register values to the PCB of that process
  • To execute another process, the OS
  • Loads register values from PCB of that process
  • Context Switch
  • Process of switching CPU from one process to
    another
  • Very machine dependent for types of registers

8
Threads and Processes
  • Most operating systems therefore support two
    entities
  • the process,
  • which defines the address space and general
    process attributes
  • the thread,
  • which defines a sequential execution stream
    within a process
  • A thread is bound to a single process.
  • For each process, however, there may be many
    threads.
  • Threads are the unit of scheduling
  • Processes are containers in which threads execute

9
Schedulers
  • Process migrates among several queues
  • Device queue, job queue, ready queue
  • Scheduler selects a process to run from these
    queues
  • Long-term scheduler
  • load a job in memory
  • Runs infrequently
  • Short-term scheduler
  • Select ready process to run on CPU
  • Should be fast
  • Middle-term scheduler
  • Reduce multiprogramming or memory consumption

10
CPU Scheduling
  • FCFS
  • LIFO
  • SJF
  • SRTF
  • Priority Scheduling
  • Round Robin
  • Multi-level Queue
  • Multi-level Feedback Queue

11
Race conditions
  • Definition timing dependent error involving
    shared state
  • Whether it happens depends on how threads
    scheduled
  • Hard to detect
  • All possible schedules have to be safe
  • Number of possible schedule permutations is huge
  • Some bad schedules? Some that will work
    sometimes?
  • they are intermittent
  • Timing dependent small changes can hide bug

12
The Fundamental Issue Atomicity
  • Our atomic operation is not done atomically by
    machine
  • Atomic Unit instruction sequence guaranteed to
    execute indivisibly
  • Also called critical section (CS)
  • When 2 processes want to execute their Critical
    Section,
  • One process finishes its CS before other is
    allowed to enter

13
Critical Section Problem
  • Problem Design a protocol for processes to
    cooperate, such that only one process is in its
    critical section
  • How to make multiple instructions seem like one?

CS1
Process 1 Process 2
CS2
Time ?
Processes progress with non-zero speed, no
assumption on clock speed Used extensively in
operating systems Queues, shared variables,
interrupt handlers, etc.
14
Solution Structure
Shared vars Initialization Process . . . .
. . Entry Section Critical Section Exit
Section
Added to solve the CS problem
15
Solution Requirements
  • Mutual Exclusion
  • Only one process can be in the critical section
    at any time
  • Progress
  • Decision on who enters CS cannot be indefinitely
    postponed
  • No deadlock
  • Bounded Waiting
  • Bound on times others can enter CS, while I am
    waiting
  • No livelock
  • Also efficient (no extra resources), fair,
    simple,

16
Semaphores
  • Non-negative integer with atomic increment and
    decrement
  • Integer S that (besides init) can only be
    modified by
  • P(S) or S.wait() decrement or block if already 0
  • V(S) or S.signal() increment and wake up process
    if any
  • These operations are atomic

semaphore S P(S) while(S 0)
S--
V(S) S
17
Semaphore Types
  • Counting Semaphores
  • Any integer
  • Used for synchronization
  • Binary Semaphores
  • Value 0 or 1
  • Used for mutual exclusion (mutex)

Process i P(S) Critical Section V(S)
Shared semaphore S Init S 1
18
Mutexes and Synchronization
semaphore S P(S) while(S 0)
S--
Init S 0
Init S 1
Process i P(S) Code XYZ V(S)
Process j P(S) Code ABC V(S)
V(S) S
19
Monitors
  • Hoare 1974
  • Abstract Data Type for handling/defining shared
    resources
  • Comprises
  • Shared Private Data
  • The resource
  • Cannot be accessed from outside
  • Procedures that operate on the data
  • Gateway to the resource
  • Can only act on data local to the monitor
  • Synchronization primitives
  • Among threads that access the procedures

20
Synchronization Using Monitors
  • Defines Condition Variables
  • condition x
  • Provides a mechanism to wait for events
  • Resources available, any writers
  • 3 atomic operations on Condition Variables
  • x.wait() release monitor lock, sleep until woken
    up
  • ? condition variables have waiting queues too
  • x.notify() wake one process waiting on condition
    (if there is one)
  • No history associated with signal
  • x.broadcast() wake all processes waiting on
    condition
  • Useful for resource manager
  • Condition variables are not Boolean
  • If(x) then does not make sense

21
Types of Monitors
  • What happens on notify()
  • Hoare signaler immediately gives lock to waiter
    (theory)
  • Condition definitely holds when waiter returns
  • Easy to reason about the program
  • Mesa signaler keeps lock and processor
    (practice)
  • Condition might not hold when waiter returns
  • Fewer context switches, easy to support broadcast
  • Brinch Hansen signaler must immediately exit
    monitor
  • So, notify should be last statement of monitor
    procedure

22
Deadlocks
  • Definition
  • Deadlock exists among a set of processes if
  • Every process is waiting for an event
  • This event can be caused only by another process
    in the set
  • Event is the acquire of release of another
    resource

Kansas 20th century law When two trains
approach each other at a crossing, both shall
come to a full stop and neither shall start up
again until the other has gone
23
Four Conditions for Deadlock
  • Coffman et. al. 1971
  • Necessary conditions for deadlock to exist
  • Mutual Exclusion
  • At least one resource must be held is in
    non-sharable mode
  • Hold and wait
  • There exists a process holding a resource, and
    waiting for another
  • No preemption
  • Resources cannot be preempted
  • Circular wait
  • There exists a set of processes P1, P2, PN,
    such that
  • P1 is waiting for P2, P2 for P3, . and PN for P1
  • All four conditions must hold for deadlock to
    occur

24
Dealing with Deadlocks
  • Proactive Approaches
  • Deadlock Prevention
  • Negate one of 4 necessary conditions
  • Prevent deadlock from occurring
  • Deadlock Avoidance
  • Carefully allocate resources based on future
    knowledge
  • Deadlocks are prevented
  • Reactive Approach
  • Deadlock detection and recovery
  • Let deadlock happen, then detect and recover from
    it
  • Ignore the problem
  • Pretend deadlocks will never occur
  • Ostrich approach

25
Safe State
  • A state is said to be safe, if it has a process
    sequence
  • P1, P2,, Pn, such that for each Pi,
  • the resources that Pi can still request can be
    satisfied by the currently available resources
    plus the resources held by all Pj, where j lt i
  • State is safe because OS can definitely avoid
    deadlock
  • by blocking any new requests until safe order is
    executed
  • This avoids circular wait condition
  • Process waits until safe state is guaranteed

26
Bankers Algorithm
  • Decides whether to grant a resource request.
  • Data structures
  • n integer of processes
  • m integer of resources
  • available1..m availablei is of avail
    resources of type i
  • max1..n,1..m max demand of each Pi for each Ri
  • allocation1..n,1..m current allocation of
    resource Rj to Pi
  • need1..n,1..m max resource Rj that Pi may
    still request
  • let requesti be vector of of resource Rj
    Process Pi wants

27
Basic Algorithm
  • If requesti gt needi then
  • error (asked for too much)
  • If requesti gt availablei then
  • wait (cant supply it now)
  • Resources are available to satisfy the request
  • Lets assume that we satisfy the request. Then
    we would have
  • available available - requesti
  • allocationi allocation i requesti
  • needi need i - request i
  • Now, check if this would leave us in a safe
    state
  • if yes, grant the request,
  • if no, then leave the state as is and cause
    process to wait.

28
Memory Management Issues
  • Protection Errors in process should not affect
    others
  • Transparency Should run despite memory
    size/location

Translation box (MMU)
legal addr? Illegal?
Physical address
Load Store
Physical memory
virtual address
CPU
fault
data
How to do this mapping?
29
Scheme 1 Load-time Linking
  • Link as usual, but keep list of references
  • At load time determine the new base address
  • Accordingly adjust all references (addition)
  • Issues handling multiple segments, moving in
    memory

OS
static a.out
0x3000
0x6000
jump 0x2000
jump 0x5000
jump 0x2000
0x4000
0x1000
30
Scheme 2 Execution-time Linking
  • Use hardware (base limit reg) to solve the
    problem
  • Done for every memory access
  • Relocation physical address logical (virtual)
    address base
  • Protection is virtual address lt limit?
  • When process runs, base register 0x3000, bounds
    register 0x2000. Jump addr 0x2000 0x3000
    0x5000

OS
a.out
0x6000
0x3000
MMU
a.out
Base 0x3000 Limit 0x2000
jump 0x2000
jump 0x2000
0x4000
0x1000
31
Segmentation
  • Processes have multiple base limit registers
  • Processes address space has multiple segments
  • Each segment has its own base limit registers
  • Add protection bits to every segment

Real memory
gcc
0x1000 0x3000 0x5000 0x6000
0x2000 0x8000 0x6000

Text seg r/o
BaseLimit?
Stack seg r/w
How to do the mapping?
32
Mapping Segments
  • Segment Table
  • An entry for each segment
  • Is a tuple ltbase, limit, protectiongt
  • Each memory reference indicates segment and offset

33
Fragmentation
  • The inability to use free memory
  • External Fragmentation
  • Variable sized pieces ? many small holes over
    time
  • Internal Fragmentation
  • Fixed sized pieces ? internal waste if entire
    piece is not used

External fragmentation
gcc
Word
??
emacs
Unused (internal fragmentation)
allocated
stack
doom
34
Paging
  • Divide memory into fixed size pieces
  • Called frames or pages
  • Pros easy, no external fragmentation

Pages typical 4k-8k
gcc
emacs
internal frag
35
Mapping Pages
  • If 2m virtual address space, 2n page size
  • (m - n) bits to denote page number, n for offset
    within page
  • Translation done using a Page Table

Virtual addr
mem
((1ltlt12)128)
3 128 (12bits)
0x1000
VPN page offset
128
page table
seg
Prot VPN PPN
?
PPN
invalid
r 3 1
36
Paging Segmentation
  • Paged segmentation
  • Handles very long segments
  • The segments are paged
  • Segmented Paging
  • When the page table is very big
  • Segment the page table
  • Lets consider System 370 (24-bit address space)

37
What is virtual memory?
  • Each process has illusion of large address space
  • 232 for 32-bit addressing
  • However, physical memory is much smaller
  • How do we give this illusion to multiple
    processes?
  • Virtual Memory some addresses reside in disk

38
Virtual Memory
  • Load entire process in memory (swapping), run it,
    exit
  • Is slow (for big processes)
  • Wasteful (might not require everything)
  • Solutions partial residency
  • Paging only bring in pages, not all pages of
    process
  • Demand paging bring only pages that are required
  • Where to fetch page from?
  • Have a contiguous space in disk swap file
    (pagefile.sys)

39
Page Faults
  • On a page fault
  • OS finds a free frame, or evicts one from memory
    (which one?)
  • Want knowledge of the future?
  • Issues disk request to fetch data for page (what
    to fetch?)
  • Just the requested page, or more?
  • Block current process, context switch to new
    process (how?)
  • Process might be executing an instruction
  • When disk completes, set present bit to 1, and
    current process in ready queue

40
Page Replacement Algorithms
  • Random Pick any page to eject at random
  • Used mainly for comparison
  • FIFO The page brought in earliest is evicted
  • Ignores usage
  • Suffers from Beladys Anomaly
  • Fault rate could increase on increasing number of
    pages
  • E.g. 0 1 2 3 0 1 4 0 1 2 3 4 with frame sizes 3
    and 4
  • OPT Beladys algorithm
  • Select page not used for longest time
  • LRU Evict page that hasnt been used the longest
  • Past could be a good predictor of the future

41
Thrashing
  • Processes in system require more memory than is
    there
  • Keep throwing out page that will be referenced
    soon
  • So, they keep accessing memory that is not there
  • Why does it occur?
  • No good reuse, past ! future
  • There is reuse, but process does not fit
  • Too many processes in the system

42
Approach 1 Working Set
  • Peter Denning, 1968
  • Defines the locality of a program
  • pages referenced by process in last T seconds of
    execution considered to comprise its working set
  • T the working set parameter
  • Uses
  • Caching size of cache is size of WS
  • Scheduling schedule process only if WS in memory
  • Page replacement replace non-WS pages

43
Working Sets
  • The working set size is num pages in the working
    set
  • the number of pages touched in the interval (t,
    t-?).
  • The working set size changes with program
    locality.
  • during periods of poor locality, you reference
    more pages.
  • Within that period of time, you will have a
    larger working set size.
  • Dont run process unless working set is in memory.

44
Approach 2 Page Fault Frequency
  • thrashing viewed as poor ratio of fetch to work
  • PFF page faults / instructions executed
  • if PFF rises above threshold, process needs more
    memory
  • not enough memory on the system? Swap out.
  • if PFF sinks below threshold, memory can be taken
    away

45
Allocation and deallocation
  • What happens when you call
  • int p (int )malloc(2500sizeof(int))
  • Allocator slices a chunk of the heap and gives it
    to the program
  • free(p)
  • Deallocator will put back the allocated space to
    a free list
  • Simplest implementation
  • Allocation increment pointer on every allocation
  • Deallocation no-op
  • Problems lots of fragmentation

heap (free memory)
allocation
current free position
46
Memory Allocator
  • What allocator has to do
  • Maintain free list, and grant memory to requests
  • Ideal no fragmentation and no wasted time
  • What allocator cannot do
  • Control order of memory requests and frees
  • A bad placement cannot be revoked
  • Main challenge avoid fragmentation

a
b
malloc(20)?
47
What happens on free?
  • Identify size of chunk returned by user
  • Change sign on both signatures (make ve)
  • Combine free adjacent chunks into bigger chunk
  • Worst case when there is one free chunk before
    and after
  • Recalculate size of new free chunk
  • Update the signatures
  • Dont really need to erase old signatures

48
Design features
  • Which free chunks should service request
  • Ideally avoid fragmentation requires future
    knowledge
  • Split free chunks to satisfy smaller requests
  • Avoids internal fragmentation
  • Coalesce free blocks to form larger chunks
  • Avoids external fragmentation

49
Malloc OS memory management
  • Relocation
  • OS allows easy relocation (change page table)
  • Placement decisions permanent at user level
  • Size and distribution
  • OS small number of large objects
  • Malloc huge number of small objects

heap
stack
data
code
50
What does the disk look like?
51
Disk overheads
  • To read from disk, we must specify
  • cylinder , surface , sector , transfer size,
    memory address
  • Transfer time includes
  • Seek time to get to the track
  • Latency time to get to the sector and
  • Transfer time get bits off the disk

Track
Sector
Rotation Delay
Seek Time
52
Disk Scheduling
  • FCFS
  • SSTF
  • SCAN
  • C-SCAN
  • LOOK
  • C-LOOK

53
RAID Levels
  • 0 Striping
  • 1 Mirroring
  • 2 Hamming Codes
  • 3 Parity Bit
  • 4 Block Striping
  • 5 Spread parity blocks across all disks
  • 01 and 10

54
Stable Storage Algo
  • Use 2 identical disks
  • corresponding blocks on both drives are the same
  • 3 operations
  • Stable write retry on 1st until successful, then
    try 2nd disk
  • Stable read read from 1st. If ECC error, then
    try 2nd
  • Crash recovery scan corresponding blocks on both
    disks
  • If one block is bad, replace with good one
  • If both are good, replace block in 2nd with the
    one in 1st

55
File System Layout
  • File System is stored on disks
  • Disk is divided into 1 or more partitions
  • Sector 0 of disk called Master Boot Record
  • End of MBR has partition table (start end
    address of partitions)
  • First block of each partition has boot block
  • Loaded by MBR and executed on boot

56
Implementing Files
  • Contiguous Allocation allocate files
    contiguously on disk

57
Linked List Allocation
  • Each file is stored as linked list of blocks
  • First word of each block points to next block
  • Rest of disk block is file data

58
Using an in-memory table
  • Implement a linked list allocation using a table
  • Called File Allocation Table (FAT)
  • Take pointer away from blocks, store in this
    table

59
I-nodes
  • Index-node (I-node) is a per-file data structure
  • Lists attributes and disk addresses of files
    blocks
  • Pros Space (max open files size per I-node)
  • Cons what if file expands beyond I-node address
    space?

60
Implementing Directories
  • When a file is opened, OS uses path name to find
    dir
  • Directory has information about the files disk
    blocks
  • Whole file (contiguous), first block
    (linked-list) or I-node
  • Directory also has attributes of each file
  • Directory map ASCII file name to file attributes
    location
  • 2 options entries have all attributes, or point
    to file I-node

61
Implementing Directories
  • What if files have large, variable-length names?
  • Solution
  • Limit file name length, say 255 chars, and use
    previous scheme
  • Pros Simple Cons wastes space
  • Directory entry comprises fixed and variable
    portion
  • Fixed part starts with entry size, followed by
    attributes
  • Variable part has the file name
  • Pros saves space
  • Cons holes on removal, page fault on file read,
    word boundaries
  • Directory entries are fixed in length, pointer to
    file name in heap
  • Pros easy removal, no space wasted for word
    boundaries
  • Cons manage heap, page faults on file names

62
Managing Free Disk Space
  • 2 approaches to keep track of free disk blocks
  • Linked list and bitmap approach

63
File System Consistency
  • System crash before modified files written back
  • Leads to inconsistency in FS
  • fsck (UNIX) scandisk (Windows) check FS
    consistency
  • Algorithm
  • Build 2 tables, each containing counter for all
    blocks (init to 0)
  • 1st table checks how many times a block is in a
    file
  • 2nd table records how often block is present in
    the free list
  • gt1 not possible if using a bitmap
  • Read all i-nodes, and modify table 1
  • Read free-list and modify table 2
  • Consistent state if block is either in table 1 or
    2, but not both

64
FS Performance
  • Access to disk is much slower than access to
    memory
  • Optimizations needed to get best performance
  • 3 possible approaches caching, prefetching, disk
    layout
  • Block or buffer cache
  • Read/write from and to the cache.

65
Block Cache Replacement
  • Which cache block to replace?
  • Could use any page replacement algorithm
  • Possible to implement perfect LRU
  • Since much lesser frequency of cache access
  • Move block to front of queue
  • Perfect LRU is undesirable. We should also
    answer
  • Is the block essential to consistency of system?
  • Will this block be needed again soon?
  • When to write back other blocks?
  • Update daemon in UNIX calls sync system call
    every 30 s
  • MS-DOS uses write-through caches

66
LFS Basic Idea
  • Structure the disk a log
  • Periodically, all pending writes buffered in
    memory are collected in a single segment
  • The entire segment is written contiguously at end
    of the log
  • Segment may contain i-nodes, directory entries,
    data
  • Start of each segment has a summary
  • If segment around 1 MB, then full disk bandwidth
    can be utilized
  • Note, i-nodes are now scattered on disk
  • Maintain i-node map (entry i points to i-node i
    on disk)
  • Part of it is cached, reducing the delay in
    accessing i-node
  • This description works great for disks of
    infinite size

67
LFS Cleaning
  • Finite disk space implies that the disk is
    eventually full
  • Fortunately, some segments have stale information
  • A file overwrite causes i-node to point to new
    blocks
  • Old ones still occupy space
  • Solution LFS Cleaner thread compacts the log
  • Read segment summary, and see if contents are
    current
  • File blocks, i-nodes, etc.
  • If not, the segment is marked free, and cleaner
    moves forward
  • Else, cleaner writes content into new segment at
    end of the log
  • The segment is marked as free!
  • Disk is a circular buffer, writer adds contents
    to the front, cleaner cleans content from the back

68
FS Examples
  • DOS
  • Win98
  • WinXP
  • UNIX FS
  • Linux ext2FS
  • NFS, AFS, LFS
  • P2P FSes

69
Network Stack Layering
Node A
Application
Node B
Application
Presentation
Presentation
Transport
Transport
Network
Network
Data Link
Data Link
Physical
Physical
Network
70
End-to-End Argument
  • What function to implement in each layer?
  • Saltzer, Reed, Clarke 1984
  • A function can be correctly and completely
    implemented only with the knowledge and help of
    applications standing at the communication
    endpoints
  • Argues for moving function upward in a layered
    architecture
  • Should the network guarantee packet delivery ?
  • Think about a file transfer program
  • Read file from disk, send it, the receiver reads
    packets and writes them to the disk

71
Packet vs. Circuit Switching
  • Reliability no congestion, in-order data in
    circuit-switch
  • Packet switching better bandwidth use
  • State, resources packet switching has less state
  • Good less control plane processing resources
    along the way
  • More data plane (address lookup) processing
  • Failure modes (routers/links down)
  • Packet switch reconfigures sub-second timescale
  • Circuit switching more complicated
  • Involves all switches in the path

72
Link level Issues
  • Encoding map bits to analog signals
  • Framing Group bits into frames (packets)
  • Arbitration multiple senders, one resource
  • Addressing multiple receivers, one wire

73
Repeaters and Bridges
  • Both connect LAN segments
  • Usually do not originate data
  • Repeaters (Hubs) physical layer devices
  • forward packets on all LAN segments
  • Useful for increasing range
  • Increases contention
  • Bridges link layer devices
  • Forward packets only if meant on that segment
  • Isolates congestion
  • More expensive

74
Network Layer
  • Two important functions
  • routing determine path from source to dest.
  • forwarding move packets from routers input to
    output

T3
T1 T3
Sts-1
T1
75
Two connection models
  • Connectionless (or datagram)
  • each packet contains enough information that
    routers can decide how to get it to its final
    destination
  • Connection-oriented (or virtual circuit)
  • first set up a connection between two nodes
  • label it (called a virtual circuit identifier
    (VCI))
  • all packets carry label

1
A
76
DNS name servers
  • Name server process running on a host that
    processes DNS requests
  • local name servers
  • each ISP, company has local (default) name server
  • host DNS query first goes to local name server
  • authoritative name server
  • can perform name/address translation for a
    specific domain or zone
  • How could we provide this service? Why not
    centralize DNS?
  • single point of failure
  • traffic volume
  • distant centralized database
  • maintenance
  • doesnt scale!
  • no server has all name-to-IP address mappings

77
Purpose of Transport layer
  • Interface end-to-end applications and protocols
  • Turn best-effort IP into a usable interface
  • Data transfer b/w processes
  • Compared to end-to-end IP
  • We will look at 2
  • TCP
  • UDP

78
UDP
  • Unreliable Datagram Protocol
  • Best effort data delivery between processes
  • No frills, bare bones transport protocol
  • Packet may be lost, out of order
  • Connectionless protocol
  • No handshaking between sender and receiver
  • Each UDP datagram handled independently

79
UDP Functionality
  • Multiplexing/Demultiplexing
  • Using ports
  • Checksums (optional)
  • Check for corruption

P3
P4
application-layer data
segment header
P1
P2
segment
H
t
M
segment
receiver
80
TCP
  • Transmission Control Protocol
  • Reliable, in-order, process-to-process, two-way
    byte stream
  • Different from UDP
  • Connection-oriented
  • Error recovery Packet loss, duplication,
    corruption, reordering
  • A number of applications require this guarantee
  • Web browsers use TCP

81
TCP Summary
  • Reliable ordered message delivery
  • Connection oriented, 3-way handshake
  • Transmission window for better throughput
  • Timeouts based on link parameters
  • Congestion control
  • Linear increase, exponential backoff
  • Fast adaptation
  • Exponential increase in the initial phase

82
Security in Computer Systems
  • In computer systems, this translates to
  • Authorization
  • Authentication
  • Audit
  • This is the Gold Standard for Security (Lampson)
  • Some security goals
  • Data confidentiality secret data remains secret
  • Data integrity no tampering of data
  • System availability unable to make system
    unusable
  • Privacy protecting from misuse of users
    information

83
Cryptography Overview
  • Encrypt data so it only makes sense to authorized
    users
  • Input data is a message or file called plaintext
  • Encrypted data is called ciphertext
  • Encryption and decryption functions should be
    public
  • Security by obscurity is not a good idea!

84
Secret-Key Cryptography
  • Also called symmetric cryptography
  • Encryption algorithm is publicly known
  • E(message, key) ciphertext D(ciphertext,
    key) message
  • Naïve scheme monoalphabetic substitution
  • Plaintext ABCDEFGHIJKLMNOPQRSTUVWXYZ
  • Ciphertext QWERTYUIOPASDFGHJKLZXCVBNM
  • So, attack is encrypted to qzzqea
  • 26! possible keys 4x1026 possibilities
  • 1 µs per permutation ? 10 trillion years to break
  • easy to break this scheme! How?
  • e occurs 14, t 9.85, q 0.26

85
Public Key Cryptography
  • Diffie and Hellman, 1976
  • All users get a public key and a private key
  • Public key is published
  • Private key is not known to anyone else
  • If Alice has a packet to send to Bob,
  • She encrypts the packet with Bobs public key
  • Bob uses his private key to decrypt Alices
    packet
  • Private key linked mathematically to public key
  • Difficult to derive by making it computationally
    infeasible (RSA)
  • Pros more security, convenient, digital
    signatures
  • Cons slower

86
Digital Signatures
  • Hashing function hard to invert, e.g. MD5, SHA
  • Apply private key to hash (decrypt hash)
  • Called signature block
  • Receiver uses senders public key on signature
    block
  • E(D(x)) x should work (works for RSA)

87
Authentication
  • Establish the identity of user/machine by
  • Something you know (password, secret)
  • Something you have (credit card, smart card)
  • Something you are (retinal scan, fingerprint)
  • In the case of an OS this is done during login
  • OS wants to know who the user is
  • Passwords secret known only to the subject
  • Simplest OS implementation keeps (login,
    password) pair
  • Authenticates user on login by checking the
    password
  • Try to make this scheme as secure as possible!
  • Display the password when being typed? (Windows,
    UNIX)

88
Salting Example
  • If the hacker guesses Dog, he has to try Dog0001,
  • UNIX adds 12-bit of salt
  • Passwords should be made secure
  • Length, case, digits, not from dictionary
  • Can be imposed by the OS! This has its own
    tradeoffs

89
One time passwords
  • Password lasts only once
  • User gets book with passwords
  • Each login uses next password in list
  • Much easier approach (Lamport 1981)
  • Uses one-way hash functions
  • User stores Server stores
  • uid, passwd uid, n, m, H hm(passwd)
  • nn-1
  • S hn(password)
  • if(hm-n(S) H)
  • then mnHSaccept
  • else reject

uid
n
S
90
Security Attacks Defenses
  • Attacks
  • Trojan Horses
  • Login spoofing
  • Logic bombs
  • Trapdoors
  • Buffer overflows
  • Viruses, worms
  • Denial of Service
  • Defenses
  • Virus Scanners
  • Lures
  • Intrusion Detection

91
Mobile Code Protection
  • Can we place extension code in the same address
    space as the base system, yet remain secure ?
  • Many techniques have been proposed
  • SFI
  • Safe interpreters
  • Language-based protection
  • PCC

92
Encoding Security
  • Depends on how a system represents the Matrix
  • Not much sense in storing entire matrix!
  • ACL column for each object stored as a list for
    the object
  • Capabilities row for each subject stored as list
    for the subject

Cs414 grades Cs415 grades Emacs
Ranveer r/w r/w Kill/resume
Tom r r/w None
Mohamed r r None
93
Protecting Capabilities
  • Prevent users from tampering with capabilities
  • Tagged Architecture
  • Each memory word has extra bit indicating that it
    is a capability
  • These bits can only be modified in kernel mode
  • Cannot be used for arithmetic, etc.
  • Sparse name space implementation
  • Kernel stores capability as objectrightsrandom
    number
  • Give copy of capability to the user user can
    transfer rights
  • Relies on inability of user to guess the random
    number
  • Need a good random number generator

94
Protecting Capabilities
  • Kernel capabilities per-process capability
    information
  • Store the C-list in kernel memory
  • Process access capabilities by offset into the
    C-list
  • Indirection used to make capabilities unforgeable
  • Meta instructions to add/delete/modify
    capabilities

95
Protecting Capabilities
  • Cryptographically protected capabilities
  • Store capabilities in user space useful for
    distributed systems
  • Store ltserver, object, rights, f(object, rights,
    check)gt tuple
  • The check is a nonce,
  • unique number generated when capability is
    created
  • kept with object on the server never sent on the
    network
  • Language-protected capabilities
  • SPIN operating system (Mesa, Java, etc.)

96
Capability Revocation
  • Kernel based implementation
  • Kernel keeps track of all capabilities
    invalidates on revocation
  • Object keeps track of revocation list
  • Difficult to implement
  • Timeout the capabilities
  • How long should the expiration timer be?
  • Revocation by indirection
  • Grant access to object by creating alias give
    capability to alias
  • Difficult to review all capabilities
  • Revocation with conditional capabilities
  • Object has state called big bag
  • Access only if capabilitys little bag has sth.
    in objects big bag

97
Why Distributed Systems?
  • Resource sharing
  • Computational speedup
  • Reliability

98
Happens-Before
  • Define a Happens-before relation (denoted by ?).
  • 1) If A and B are events in the same process, and
    A was executed before B, then A ? B.
  • 2) If A is the event of sending a message by one
    process and B is the event of receiving that
    message by another process, then A ? B.
  • 3) If A ? B and B ? C then A ? C.

99
Partial Ordering
Pi -gtPi1 Qi -gt Qi1 Ri -gt Ri1
R0-gtQ4 Q3-gtR4 Q1-gtP4 P1-gtQ2
100
Impossibility of Consensus
  • Network characteristics
  • Synchronous - some upper bound on
    network/processing delay.
  • Asynchronous - no upper bound on
    network/processing delay.
  • Fischer Lynch and Paterson showed
  • With even just one failure possible, you cannot
    guarantee consensus.
  • Essence of proof Just before a decision is
    reached, we can delay a node slightly too long to
    reach a decision.
  • Real world solutions
  • Paxos, Randomized Consensus (P1 is good enough)

101
Good luck!
Write a Comment
User Comments (0)
About PowerShow.com