advanced operating systems - fall 2009 lecture 3 – january 14, 2009
Post on 05-Jan-2016
45 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
Advanced Operating Systems - Fall 2009Lecture 3 – January 14, 2009
Dan C. Marinescu
Email: dcm@cs.ucf.edu
Office: HEC 439 B
2
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
3
Last, Current, Next Lecture
Last time: The relationship between physical systems and models Layering Virtualization.
Today: 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
4
Classes of requirements for system design
Functionality 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.
Performance Quantity/Quality tradeoffs. Fault-tolerance is the ultimate performance factor.
Cost
5
Resource sharing models
Time-Shared Computer System
HSHS
HSHS
HS
HS
HS
Switch
HS – Homo Sapiens
HS Personal Computer
A. Many-to-one
B. One-to-one
C. Many-to-many
HS Computer System
Computer System
Computer SystemHS
Internet
CI
HS – Homo SapiensCI- Computing Instrument
CI
6
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
7
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
8
BSD Unix memory layout
9
OS structures
Two views of the OS. Example: UNIXSystem ProgramsOS services
System callsAPIs
10
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.
11
UNIX System Structure
12
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
13
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
14
Operating System Services
User interface; Command-Line Interface (CLI), Graphics User Interface (GUI), Batch Queuing Systems
Program execution 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.
15
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.
16
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)
17
User/OS interface – CLI,GUI, BQS
CLI (Command Line Input () allows direct command entry; it fetches a command from user and executes it.
Implemented by the kernel, by systems program shells
Built-in or just names of programs. If the latter, adding new features doesn’t require shell
modification
GUI - desktop metaphor interface Batch Queuing Systems.
18
Memory layout MS-DOS
(a) At system startup (b) running a program
19
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?
20
Example: system call to copy the contents of one file to another
21
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
22
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.
23
API – System Call – OS Relationship
24
Solaris 10 dtrace Following System Call
25
Example: C program invoking printf() library call, which calls write() system call in Unix
26
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.
27
Parameter Passing via Table
28
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?)
29
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;
30
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.
31
How
Arrange the passwordArgument such that its first character is the last character of a page The next page is unassigned.
Try every character allowable in a password as first 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…..
32
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.
33
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.
34
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.
35
State
Finite versus infinite state systems Hardware verification a reality. Software verification; is it feasible?
State of a physical system Microscopic Macroscopic state
State of a processor State of a program Snapshots - checkpointing State of a distributed system – the role of time.
36
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
top related