Some Theory Review

1. Some Theory Review COMP346/5461 - Operating Systems Revision 1.2 September 30, 2003 Serguei A. Mokhov, mokhov@cs.concordia.ca

2. OS Need Multiprogramming vs. Uniprogramming I/O Interrupts vs. Polling DMA Programs, Processes and Threads Revisited Synchronous vs. Asynchronous Message Passing Trap and Interrupts Common Problems in Multiprogramming Synchronization Deadlock Mutual exclusion, critical sections… Security Topics Serguei A. Mokhov, mokhov@cs.concordia.ca

3. OS: The Need • A typical example: • You have a responsibility of designing a dedicated system to control something (water pumps, conveyor production, etc). • Dedicated implies a single user and a single process dedicated process. • Discussion: • Would you still include an OS into the design of such a system? (key things: security and abstraction) Serguei A. Mokhov, mokhov@cs.concordia.ca

4. OS: Multiprogramming vs. Uniprogramming • A typical problem: • There a need to have a system where throughput (number of jobs completed within a given time) is the most important factor. • Experiments show, however, that the context switch time is a lot more than a typical execution time of an average process in the mm-OS. • Discussion: • Again, as a system designer, would you go with multiprogramming or uniprogramming? Serguei A. Mokhov, mokhov@cs.concordia.ca

5. I/O: Interrupts vs. Polling (1) • Polling (sync. I/O): CPU routinely checks device’s status via controller: • CPU: “Dear device driver (DD), is the device done?” • DD: “Nope” • CPU: “Dear device driver (DD), is the device done?” • DD: “Nope, not yet” • CPU: “Dear device driver (DD), is the device finally done???? I’m kinda wasting my time waiting here!” • DD: “Patience, it almost done. A couple more cycles…” Serguei A. Mokhov, mokhov@cs.concordia.ca

6. I/O: Interrupts vs. Polling (2) • Interrupts (asynchronous I/O): • CPU: “Dear device driver, say the device to do this and that, OK?” • DD: “Sure. [To device]: CPU wants you to do this and that. Let us know when you’re done, k?” • Device: No prob. [starts doing I/O] • CPU: [to itself]: oh, I have so much to do! [goes and does smth else] • Device: [busy doing I/O an finally finishes]: Hey CPU! • CPU: [suddenly interrupted by the Device] What is it? • Device: I’m done with I/O. I though you might want to know… Serguei A. Mokhov, mokhov@cs.concordia.ca

7. I/O: No DMA • Usually it’s the CPU who does the transfer of the data from a device to the memory and back: • CPU: “Hey DD! I need some data for that process. Could you arrange some?” • DD: “Yep.” [To HDD]: “Hey HDD,CPU needs some data for that process, do you have it?” • HDD: “Here’s some” • DD: “Oh cool, CPU, here’s some data!” • CPU: [gets the data, and places it to the memory and continues with the process] • HDD: “Here’s some more, I forgot since last time” • DD: “OK” • CPU: “What, again data? OK…” [takes it from DD and places to the memory of the process] Serguei A. Mokhov, mokhov@cs.concordia.ca

8. I/O: DMA • CPU is more free from useless work when it has a friendly DMA (Direct Memory Access) controller: • CPU: “DD, I need that data for that process from HDD. It should be between 0x46F46F and 0x46FFFF about this big.” [goes and does smth else] • DD: “Hey DMA! Wake up, you heard what CPU said…” • DMA: “Yep.” [Contacts HDD, grabs specified block of data, and puts it to the specified place]: “CPU: Me done!” Serguei A. Mokhov, mokhov@cs.concordia.ca

9. Programs, Processes, and Threads • Once again, what are a program, a process and a thread? • Which one static, dynamic? • What does a process have (consist of)? • How threads are different from processes? • What do they consist of? Serguei A. Mokhov, mokhov@cs.concordia.ca

10. Synchronous vs. Asynchronous • Message Passing • A typical async example is email. The sender doesn’t wait for the recipient to get it. • A sync example is a bounded buffer. Sync is needed, so that the sender waits for the receiver to get the message or a part of it before proceeding to the next part. • Side question: why would be advisable to have processes’ mailboxes for message passing in the kernel space? Problems (hint: size and data loss)? Solutions? Serguei A. Mokhov, mokhov@cs.concordia.ca

11. Synchronous vs. Asynchronous (2) • Interrupts • System Call Interface – switch between user and kernel mode – a syscall executes trap – a sync interrupt (which is processed in the kernel as ordinary interrupt) • From devices – async. Why? Serguei A. Mokhov, mokhov@cs.concordia.ca

12. Interrupts and Trap Revisited • Neither interrupt nor trap are function calls! • Interrupt is an event, or a signal (do not confuse with UNIX signals), notifying the system that something happened. • Interrupts are not necessarily used to switch between processes (in scheduling), but cause a context switch. • Trap is a software interrupt, it's synchronous, whereas an ordinary interrupt is asynchronous. • Trap is a CPU instruction, which is invoked when a user program wants either some service from an OS (system call) or causes an error (division by zero, segmentation fault, page fault, etc.). Serguei A. Mokhov, mokhov@cs.concordia.ca

13. User-running syscall() - trap exit() Kernel-running Zombie wait() Blocked Ready Common Interface: open, close, read, write The “Big” Picture System Call Interface App App App App App User mode SW Kernel mode MM kernel PM HDDD PTRDD CDDD int Ready queue Bus CPU: add mult mov trap HW DMA Ctl Mon Ctl Ptr Ctl CD Ctl int int (IRQ) Serguei A. Mokhov, mokhov@cs.concordia.ca

14. Common Problems in Multiprogramming • Synchronization (act of communication). • Mutual exclusion and critical sections (only one process at a time executing a given section of a code, usually operating on a shared resource). • Deadlock (two or more processes waiting for each other on some resources). • Context switch overhead. • Security (processes must not interfere with other processes, and unauthorized users shouldn’t be able to interfere with other users). • All the above make the system much harder to implement. • Why is multiprogramming is usually still better? (hint: CPU utilization) Serguei A. Mokhov, mokhov@cs.concordia.ca

15. Basic Security • Security != Protection • OS Protection is needed between: • Processes of one user from others in multiuser environment. • Processes of the same user (isolation). • OS and the users (various resource managers and device drivers vs. application software) • Various components of the OS itself. Serguei A. Mokhov, mokhov@cs.concordia.ca

16. Basic Security (2) • OS on the network: • The system has to provide CIAN: • Confidentiality • Integrity • Availability • Authentication • Authorization • Access Control • Hence, the compilation of the protocols. Serguei A. Mokhov, mokhov@cs.concordia.ca

17. Basic Security (3) • Binary privilege model is NOT enough: • Binary in a sense: GOD vs. LAMER • I.e. root (or superuser or monitor) vs. user • Exploiting various system vulnerabilities a user can become god. • E.g. buffer overflows in trusted / privileged (falsely) software. • Other bugs. • Thus, sandboxing such programs and filtering system calls and having more fine-grained roles and ACLs and permissions. Serguei A. Mokhov, mokhov@cs.concordia.ca

18. Next Tutorial • Synchronization • Semaphores • Your questions, as usual Serguei A. Mokhov, mokhov@cs.concordia.ca