Interrupt and System Call in Linux Today
Total Page:16
File Type:pdf, Size:1020Kb
Interrupt and System Call in Linux Today Interrupts in Linux System calls in Linux Monolithic kernel All OS components run in kernel mode User mode APP Kernel mode FS Mem Net Why good? ▪ Can be efficient. Cross-component access cheap Why bad? ▪ No boundaries Big, complex kernel hard to change • Hard to do new stuff in OS OS researchers unhappy • No flexibility for apps. Hard to customize for speed (web server) ▪ Trusted computing base (TCB) large, one error entire kernel crash, or be compromised Virtual Machine Virtual Machine Monitor (VMM): kernel that provides hardware interface APP APP APP User mode OS OS OS Kernel mode VMM Why good? ▪ Isolation. Strong protection between VMs ▪ Consolidation. One physical machine, multiple VMs ▪ Mobility. Can move VMs around ▪ Standardization: same hw better system mgmt Virtual Machine (cont) Normal operating system environment: ▪ running in supervisor mode ▪ full access to machine state and I/O devices Virtualized guest operating systems: ▪ running in user mode ▪ no direct access to machine state Tasks of the virtual machine monitor: ▪ reconciling the virtual and physical architecture ▪ preventing virtual machines from interfering with each other or the monitor ▪ Do it fast? Not a easy job … Linux kernel structure Core + dynamically loadable modules Modules include: device drivers, file systems, network protocols, etc Modules were originally developed to support the conditional inclusion of device drivers ▪ Early OS kernels would need to either: • include code for all possible devices or • be recompiled to add support for a new device ▪ Now, Modules can be dynamically loaded and unloaded Modules are used extensively Linux kernel structure (cont.) Applications System Libraries (libc) System Call Interface I/O Related Process Related File Systems Scheduler Networking Memory Management Modules Device Drivers IPC Architecture-Dependent Code Hardware Types of Interrupts on 80386 Interrupts, asynchronous, from external devices, not related to code running ▪ Maskable interrupts ▪ Nonmaskable interrupts (NMI): hardware error Exceptions, synchronous, raised by CPU ▪ Processor-detected exceptions: • Faults — correctable; offending instruction is retried • Traps — often for debugging; instruction is not retried • Aborts — major error (hardware failure), RIP wrong ▪ Programmed exceptions: • Requests for kernel intervention (software intr/syscalls) Faults Instruction would be illegal to execute Examples: ▪ Writing to a memory segment marked ‘read- only’ ▪ Reading from an unavailable memory segment (on disk) page fault ▪ Executing a ‘privileged’ instruction Detected before incrementing the IP The causes of ‘faults’ can often be ‘fixed’ Traps A CPU might have been programmed to automatically switch control to a ‘debugger’ program after it has executed an instruction That type of situation is known as a ‘trap’ It is activated after incrementing the IP Handling Exceptions Most error exceptions — divide by zero, invalid operation, illegal memory reference, etc. — translate directly into signals This isn’t a coincidence. The kernel’s job is fairly simple: send the appropriate signal to the current process ▪ force_sig(sig_number, current); That will probably kill the process, but that’s not the concern of the exception handler One important exception: page fault An exception can (infrequently) happen in the kernel ▪ die(); // kernel oops Interrupt # assignment Total possible 0-255 Interrupt ID numbers First 32 reserved by Intel for NMI and exceptions OS’s such as Linux are free to use the remaining 224 available interrupt ID numbers for their own purposes (e.g., for service-requests from external devices, or for other purposes such as system-calls) Examples : ▪ 0: divide-overflow fault ▪ 3: breakpoint ▪ 8: fault while handling interrupt ▪ 14: Page-Fault Exception ▪ 128: system calls Interrupt Descriptor Table The ‘entry-point’ to the interrupt-handler is located via the Interrupt Descriptor Table (IDT) IDT: “gate descriptors” ▪ Location of handler ▪ Descriptor Privilege Level (DPL), prevent bad access • Can invoke only when current privilege level (CPL) < DPL • This is just the mode bit for protection ▪ Gates (slightly different ways of entering kernel) • Interrupt gate: disables further interrupts • Trap gate: further interrupts still allowed • Task gate: includes TSS to transfer to (used when RIP is bad, or hardware failure) Loading an Interrupt handler Hardware locates the proper gate descriptor for this interrupt vector, and locates the new context Verifies Current Privilege Level (CPL) <= Descriptor Privilege level (DPL) Load a new stack pointer if needed Hw saves old IP, on rcx Set IP, etc to interrupt handler = invoke handler ▪ disable interrupt by unsetting IF bit in eflags register Handler saves old CPU state on r11 1 5 The system-call jump-table There are approximately 300 system-calls Any specific system-call is selected by its ID- number (it’s placed into register rax) It would be inefficient to use if-else tests or even a switch-statement to transfer to the service-routine’s entry-point Instead an array of function-pointers is directly accessed (using the ID-number) This array is named ‘sys_call_table[]’ .