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

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

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: UNIX • System Programs • OS services • System calls • APIs

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 stackby 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 toLength(directoryPassword)do if directoryPassword[i] ≠passwordArgument[i] then Wait 3 seconds; returnBadPassword; endif endfor connectToDirectory; returnsuccess;

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