* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download slides
Survey
Document related concepts
Mobile operating system wikipedia , lookup
Plan 9 from Bell Labs wikipedia , lookup
Copland (operating system) wikipedia , lookup
Distributed operating system wikipedia , lookup
Spring (operating system) wikipedia , lookup
Unix security wikipedia , lookup
Linux kernel wikipedia , lookup
Security-focused operating system wikipedia , lookup
Transcript
OS Structure Andrew Whitaker CSE451 Operating System: What Are They Good For? Multiprogramming Process = virtualized address space + CPU High-level abstractions File system, TCP/IP sockets Protection Protection Challenge: OS must safely support multiple protection domains OS as “law enforcement” Goals: Protect applications from each other Protect applications from themselves Prevent malicious application from taking control of the OS The User/Kernel boundary Kernel mode gives the OS special privileges User/kernel boundary is enforced by hardware Applications enter kernel mode by executing a system call user kernel App App OS App Examples of Privileged Instructions Manipulating I/O devices Interrupt enable/disable Halt instruction Manipulating protected registers Such as user/kernel mode control System Call Overview User program invokes helper procedure e.g., read, write, gettimeofday Helper passes control to the OS Indicates the system call number Packages user arguments into registers Issues a software interrupt (or trap) OS saves user state (registers) OS invokes appropriate system call handler OS returns control to the user application A kernel crossing illustrated Firefox: read(int fileDescriptor, void *buffer,int numBytes); ) package arguments user mode trap to kernel mode kernel mode trap handler save registers find sys_read( ) handler in vector table sys_read( ) kernel routine restore app state, return to user mode, resume Kernel Entry Points Interrupts Disk, network, timer, etc. Software interrupts (traps, exceptions) System calls Protection violations e.g,. User executes a privileged instructions Page faults Error conditions e.g., divide by zero, illegal opcode Kernel Entry Points Applications Via applications instructions (traps) System calls Protection violations OS Kernel e.g,. User executes a privileged instructions Page faults Error conditions Hardware e.g., divide by zero, illegal opcode Via hardware interrupts Errors in the OS Q: What happens if the OS kernel divides by zero? Blue Screen :-( Memory Protection Problem #1: OS must protect applications from each other Solution: virtual memory Problem #2: Kernel must protect its own code and data Solution: Partition the address space Kernel region requires privileged mode access Simplified Linux Address Space Layout user space Accessible by kernel and application kernel space Accessible by kernel only Memory Protection Trickiness Consider a hypothetical system call, zeroFill, which fills a user buffer with zeroes: zeroFill(char* buffer, int bufferSize); The following kernel implementation of zeroFill contains a security vulnerability. What is the vulnerability, and how would you fix it? void sys_zeroFill(char* buffer, int bufferSize) { for (int i=0; i < bufferSize; i++) { buffer[i] = 0; }} Solution The user buffer pointer is untrusted and could point anywhere. In particular, it could point inside the kernel address space. This could lead to a system crash or security breakdown. Fix: verify the pointer is a valid user address Follow-up Question Is it a security risk to execute the zeroFill function in user-mode? void zeroFill(char* buffer, int bufferSize) { for (int i=0; i < bufferSize; i++) { buffer[i] = 0; } } Solution No. User-mode code does not have permission to access the kernel’s address space. If it tries, the hardware raises an exception, which is safely handled by the OS More generally, no user mode code should ever be a security vulnerability. Unless the OS has a bug… Two Stacks are Better than One? Processes generally have two stacks One in user space One in kernel space The stack is switched (by hardware) on each kernel entry, exit. Why? user space kernel space Sample Test Question What bad thing could happen if a user application could overwrite the interrupt dispatch vector? How does the OS prevent this? Solution An application could: 1) Prevent I/O operations from ever completing; 2) Prevent time from advancing, thus dominating the processor Applications cannot modify the interrupt vector because it lives in the kernel address space. Any attempt to modify the interrupt vector raises a kernel exception, which is safely handled. Sample Test Question What prevents an application from directly reading from the disk, instead of passing through file system access control checks? Solution Instructions for manipulating I/O devices are privileged. Any attempt to use them in user mode raises a protection exception, which the operating system gracefully handles.