Advanced operating systems fall 2009 lecture 3 january 14 2009
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

Advanced Operating Systems - Fall 2009 Lecture 3 – January 14, 2009 PowerPoint PPT Presentation


  • 104 Views
  • Uploaded on
  • Presentation posted in: General

Advanced Operating Systems - Fall 2009 Lecture 3 – January 14, 2009. Dan C. Marinescu Email: [email protected] Office: HEC 439 B. Class organization. Class webpage: www.cs.ucf.edu/~dcm/Teaching/OperatingSystems Text: “Operating system concepts” by Silberschatz, Gavin, Gagne

Download Presentation

Advanced Operating Systems - Fall 2009 Lecture 3 – January 14, 2009

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Advanced Operating Systems - Fall 2009Lecture 3 – January 14, 2009

Dan C. Marinescu

Email: [email protected]

Office: HEC 439 B


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


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


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


Resource sharing models


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


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


BSD Unix memory layout


OS structures

  • Two views of the OS.

  • Example: UNIX

  • System Programs

  • OS services

    • System calls

    • APIs


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.


UNIX System Structure


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


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


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.


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.


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)


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.


Memory layout MS-DOS

(a) At system startup (b) running a program


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?


Example: system call to copy the contents of one file to another


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


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.


API – System Call – OS Relationship


Solaris 10 dtrace Following System Call


Example: C program invoking printf() library call, which calls write() system call in Unix


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 stackby the program and popped off the stack by the operating system.


Parameter Passing via Table


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?)


The CONNECT system call

for i:=0 toLength(directoryPassword)do

if directoryPassword[i] ≠passwordArgument[i] then

Wait 3 seconds;

returnBadPassword;

endif

endfor

connectToDirectory;

returnsuccess;


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.


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…..


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.


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.


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.


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.


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


  • Login