advanced operating systems fall 2009 lecture 3 january 14 2009
Download
Skip this Video
Download Presentation
Advanced Operating Systems - Fall 2009 Lecture 3 – January 14, 2009

Loading in 2 Seconds...

play fullscreen
1 / 36

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


  • 144 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
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
  • 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.
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.
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.
slide31
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
ad