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


  • 99 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 2009 lecture 3 january 14 2009

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

Dan C. Marinescu

Email: [email protected]

Office: HEC 439 B


Class organization

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, 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

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

Resource sharing models


Multiprogramming needed for efficiency

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

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

BSD Unix memory layout


Os structures

OS structures

  • Two views of the OS.

  • Example: UNIX

  • System Programs

  • OS services

    • System calls

    • APIs


Operating system structures

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

UNIX System Structure


System programs

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 programs1

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

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

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

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

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

Memory layout MS-DOS

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


System calls

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

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


Api example readfile in win32 api

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

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

API – System Call – OS Relationship


Solaris 10 dtrace following system call

Solaris 10 dtrace Following System Call


Example c program invoking printf library call which calls write system call in unix

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


Methods to pass parameters to the os

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

Parameter Passing via Table


Lampson generality can lead to complexity

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

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

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.


Advanced operating systems fall 2009 lecture 3 january 14 2009

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

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

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

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

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