Mid Review of Class Argument ValidationandSynchronization Guidelines April 26, 2000 Instructor: Gary Kimura
Today’s Lecture • Quick class outline of what we have and will be covering • Two loose ends • Argument validation • Choosing the right synchronization tool • Review of material so far • But before I forget, start reading Chapter 8 for Friday
Class Material Breakdown • OS Kernel, processes, threads, scheduling, synchronization, and deadlocks (1st third of class) • Memory management, I/O, File Systems, Secondary storage (2nd third of class) • Special topics such as distributed systems, accounting, security, RPC, etc. (remaining time)
Argument Validation • User supplied parameters are never to be trusted • The kernel must validate all user supplied parameters • The range of the input values must be verified • Output buffers must be verified as writeable • Input buffers must be readable and contain correct values • Privileges must be checked if applicable • Remember that kernel mode can access data that user mode cannot. So the kernel must not blindly assume pointers are good just because the kernel can access the memory
Probe and Capture • One method used is to probe and capture user parameters • Probing is verifying that a pointer supplied by the user is valid • Capturing is making a copy of any user supplied input data buffer • All copying of data to and from user buffers must be “bullet-proof” • Open file example • OpenFile( IN PSTRING FileName, … ); • The kernel must probe and capture the file name into a private buffer. Then it can work through trying to actually open the file. • What can happen if the kernel keeps using the user buffer?
Some Argument Validation Gotchas • Range checking of input values is not too hard but what happens if… • The user supplied a good kernel address for either an input or output buffer? • The user unmaps or remaps a buffer while the kernel is using it? • System calls that take a pointer to a structure that itself contains pointers are a validations worse nightmare.
Choosing the Right Synchronization Tool • Often times it is helpful to view the necessary synchronization method as either code centric or data centric • Code Centric meaning that we want to structure the program such that executing sections of code are mutually exclusive • Data Centric meaning that we want controlled access to a data item. The latter one can be shared and/or exclusive access. • All the synchronization methods can be used for code or data centric access but keeping the correct paradigm in minds helps in the overall design.
Synchronization Tools • Spinlocks - for exclusive access, cheap and fast, but serializes a lot, and wastes coprocessor cycles, other usage limitations Great for code centric exclusion • InterlockedInstructions - cheap and fast, somewhat difficult to use. Great for small data centric synchronization • Mutexes - for exclusive access, sort of cheap, can lead to context switches. Great for code centric exclusion • Semaphores - sort of cheap, can lead to context switches. In the raw form somewhat difficult to use. • Events - sort of cheap, can lead to context switches. Great for synchronizing threads. • Full blown reader/writer resources - Most expensive, but a great programming paradigm to use especially for data centric access
Review of Material so Far • Major components and functions of an OS • Hardware support • Processes/threads and scheduling • Synchronization and deadlocks (just talked about)
Major Components • Process management • Memory management • I/O management • Secondary storage management • File management • Protection system • Accounting • Etc.
Hardware Support • Timers • Synchronization (atomic instructions) • Memory protection • I/O control and operation • Interrupts and exceptions • Dual execution modes • Protected instructions • System calls
Processes/Threads and Scheduling • What is a process/thread • Process/threads states • Scheduling algorithms • First-Come First-Served • Shortest Job First • Round Robin • Priority based scheduling • What is a context switch