Transcript Lecture3

Advanced Operating Systems - Fall 2009
Lecture 3 – January 14, 2009
Dan C. Marinescu
Email: [email protected]
Office: HEC 439 B
1
Class organization

Class webpage:
 www.cs.ucf.edu/~dcm/Teaching/OperatingSystems

Text:
 “Operating system concepts” by Silberschatz,
Gavin, Gagne

Office hours: M, Wd, 3:00 – 4:30 PM
2
Last, Current, Next Lecture

Last time:




Today:







The relationship between physical systems and models
Layering
Virtualization.
Requirements for system design
Resource sharing models: multiprogramming and multitasking
Operating Systems Structures
The complexity of computing and communication systems
State
Butler Lampson’s hints for system design
Next time:

Processes and Threads
3
Classes of requirements for system design

Functionality




Performance



Does the system perform the functions it was designed for?
How easy is it to use the system?
How secure is the use of the system? Security tradeoffs.
Quantity/Quality tradeoffs.
Fault-tolerance is the ultimate performance factor.
Cost
4
Resource sharing models
A. Many-to-one
HS – Homo Sapiens
HS
HS
HS
HS HS
HS HS
Switch
Time-Shared
Computer
System
B. One-to-one
HS
HS – Homo Sapiens
CI- Computing Instrument
Personal
Computer
C. Many-to-many
Computer System
HS CI
Computer System
Internet
HS
CI
Computer System
5
Multiprogramming  needed for efficiency

Single user cannot keep CPU and I/O devices
busy at all times

Multiprogramming organizes jobs (code and data)
so CPU always has one to execute

A subset of total jobs in system is kept in memory

One job selected and run via job scheduling (

When it has to wait (for I/O for example), OS
switches to another job
6
Interactive computing - Timesharing

CPU switches jobs frequently so that users
can interact with each job while it is
running, creating




Response time should be < 1 second
Each user has at least one program executing
in memory process
If several jobs ready to run at the same time 
CPU scheduling
If processes don’t fit in memory, swapping
moves them in and out to run
7
BSD Unix memory layout
8
OS structures
Two views of the OS.
 Example: UNIX
 System Programs
 OS services

System calls
 APIs

9
Operating-System Structures

Two views of the OS:

The friendly view a collection of services to assist
the user




Operating System Services
The Interface User - Operating System
System Calls
The not so friendly view a gatekeeper who
controls user’s access to system resources


OS services implement restricted access; e.g., I/O
privileged operations.
OS hides from the user many decisions; e.g., CPU
scheduling, buffering strategies, caching, etc.
10
UNIX System Structure
11
System Programs

Types








File manipulation
Status information
File modification
Programming language support
Program loading and execution
Communications
Application programs
Most users’ view of the operation system is
defined by system programs, not the actual
system calls
12
System Programs

Provide a convenient environment for program
development and execution


Some are simply user interfaces to system calls; others are
considerably more complex
Status information




Some ask the system for info - date, time, amount of available
memory, disk space, number of users
Others provide detailed performance, logging, and debugging
information
Typically, these programs format and print the output to the
terminal or other output devices
Some systems implement a registry - used to store and
retrieve configuration information
13
Operating System Services

User interface;




Program execution




Command-Line Interface (CLI),
Graphics User Interface (GUI),
Batch Queuing Systems
load a program into memory and run the program,
end execution, either normally or abnormally (indicating error)
I/O operations
File-system manipulation 



Create/Delete, Read/Write files and directories;
search files and directories;
list file Information;
permission management.
14
Operating System Services (Cont’d)

Communications among processes on the same
computer or over a network:



Message passing
Shared memory
Exception handling



Hardware errors – machine checks (CPU, memory hardware,
I/O devices)
Timer interrupts.
Program exceptions.
15
More operating system services


Monitoring and debugging support. Traces.
Performance monitoring




Counters
State information
Accounting
Protection and security

Protection  access to system resources is controlled

Security of the system from outsiders



user authentication
protect external I/O devices from invalid access attempts
Utilities (system backup, maintenance)
16
User/OS interface – CLI,GUI, BQS

CLI (Command Line Input () allows direct
command entry; it fetches a command from
user and executes it.

Implemented




Built-in or just names of programs.



by the kernel,
by systems program
shells
If the latter, adding new features doesn’t require shell
modification
GUI - desktop metaphor interface
Batch Queuing Systems.
17
Memory layout MS-DOS
(a) At system startup (b) running a program
18
System Calls




Programming interface to OS services.
Typically written in a high-level language (C or C++)
Accessed by programs via Application Program
Interface (API).
Common APIs:




Win32 API  Microsoft Windows;
POSIX API  POSIX-based systems (UNIX, Linux, and Mac
OS X)
Java API for the Java virtual machine (JVM)
Why use APIs rather than system calls?
19
Example: system call to copy the contents
of one file to another
20
API Example: ReadFile() in Win32 API

The parameters passed to ReadFile()





HANDLE file—the file to be read
LPVOID buffer—a buffer to read into and write from
DWORD bytesToRead— number of bytes to be read
LPDWORD bytesRead—number of bytes read during the last read
LPOVERLAPPED ovl—indicates if overlapped I/O is being used
21
System Call Implementation

Typically, a number associated with each system call. The
system-call interface maintains a table indexed according to
these numbers.

The system call interface invokes intended system call in OS
kernel and returns status of the system call and any return
values.

The caller



need know nothing about how the system call is implemented
must obey API and understand what OS will do as a result call
Most details of OS interface hidden from programmer by API.
Managed by run-time support library.
22
API – System Call – OS Relationship
23
Solaris 10 dtrace Following System Call
24
Example: C program invoking printf() library
call, which calls write() system call in Unix
25
Methods to pass parameters to the OS


In registers. What if more parameters than
registers?
Methods do not limit the number or length of
parameters being passed:


In a block, or table, in memory, and address of block
passed as a parameter in a register. E.g., Linux and
Solaris
On the stack. Parameters pushed, onto the stack by the
program and popped off the stack by the operating
system.
26
Parameter Passing via Table
27
Lampson: Generality can lead to
complexity.

System call implementation in Tenex:




A system call  machine instruction of an extended machine
A reference to an unassigned virtual page causes a trap to the
user’s program even if caused by a system call.
All arguments (including strings) to system calls passed by
reference.
The CONNECT system call  access to a directory.


One of its arguments a string, the password for the directory.
If the password is wrong the call fails after 3 seconds (why 3s?)
28
The CONNECT system call
for i:=0 to Length(directoryPassword) do
if directoryPassword[i] ≠passwordArgument[i] then
Wait 3 seconds;
return BadPassword;
endif
endfor
connectToDirectory;
return success;
29
How to exploit this implementation to guess
the password

If the password:


is n characters long;
a character is encoded in 8 bits;
I need in average 256n/2 trials to guess the password.

In this implementation of CONNECT in average I can
guess the password in 128n trials.


How?
What is wrong with the implementation.
30
How

Arrange the passwordArgument such that



Try every character allowable in a password as first



its first character is the last character of a page
The next page is unassigned.
If CONNECT returns badArgument  the guess was wrong
If the system reports a reference to an unassigned page  the
guess is correct.
Try every character allowable in a password as second…..
31
What is wrong with the implementation?

The interface provided by an ordinary memory
reference instruction in system code is complex.

An improper reference is sometimes reported to the
user without the system code getting control first.
32
The complexity of computing and
communication systems

The physical nature and the physical properties of
computing and communication systems must be well
understood and the system design must obey the laws
of physics.

The behavior of the systems is controlled by
phenomena that occur at multiple scales/levels. As
levels form or disintegrate, phase transitions and/or
chaotic phenomena may occur.

Systems have no predefined bottom level; it is never
known when a lower level phenomena will affect how
the system works.
33
The complexity of computing and
communication systems (cont’d)

Abstractions of the system useful for a particular
aspect of the design may have unwanted
consequences at another level.
 A system depends on its environment for its
persistence, therefore it is far from equilibrium.
 The environment is man-made; the selection required
by the evolution can either result in innovation,
generate unintended consequences, or both.
 Systems are expected to function simultaneously as
individual entities and as groups of systems.
 The systems are both deployed and under
development at the same time.
34
State

Finite versus infinite state systems



State of a physical system






Hardware verification a reality.
Software verification; is it feasible?
Microscopic
Macroscopic state
State of a processor
State of a program
Snapshots - checkpointing
State of a distributed system – the role of time.
35
Statefull versus stateless systems

Transaction-oriented systems are often stateless



Web server
NFS server
Maintaining a complex state:



Tedious
Complicates the design
Makes error recovery very hard
36