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