Transcript slides

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.