Advanced operating systems fall 2009 lecture 3 january 14 2009
Download
1 / 36

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


  • 143 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Advanced Operating Systems - Fall 2009 Lecture 3 – January 14, 2009' - metea


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



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



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.



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?



Api example readfile in win32 api
API Example: ReadFile() in Win32 API another

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

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





Methods to pass parameters to the os
Methods to pass parameters to the OS calls write() system call in Unix

  • 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 calls write() system call in Unix


Lampson generality can lead to complexity
Lampson: Generality can lead to complexity. calls write() system call in Unix

  • 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 calls write() system call in Unix

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 calls write() system call in Unix

  • 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 calls write() system call in Unix

  • 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? calls write() system call in Unix

  • 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 calls write() system call in Unix

  • 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 (cont’d)

  • 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 (cont’d)

  • Transaction-oriented systems are often stateless

    • Web server

    • NFS server

  • Maintaining a complex state:

    • Tedious

    • Complicates the design

    • Makes error recovery very hard


ad