Processor Exceptions A survey of the x86 exceptions and mechanism for handling faults, traps, and aborts

‘Before-the-fact’ errors The CPU may fetch an instruction which it cannot correctly execute (due to an invalid operand or insufficient privilege-level, or to the instruction’s opcode not being defined) A few examples are: –Attempting to perform division by zero –Attempting to exceed memory-segment limits –Attempting to modify a ‘read-only’ segment

‘After-the-fact’ errors Also the cpu may perform some operation that results in an incorrect or illegal value (due to limits on the CPU register-sizes or to limits on the supported data-formats) A few examples: –Add positive numbers, but get a negative total –Store an array-entry beyond the array-bounds –Take square-root of a real value less than 0.0

“privileged” instructions In Protected-Mode the instructions below can only be executed at ring0 (i.e., if the CPU’s Current Privilege Level is zero): –‘MOV’ to/from a control-register (e.g., CR0) –‘MOV’ to/from a debug-register (e.g., DR7) –Modifying a system segment-register (i.e., ‘LGDT’ / ’LIDT’ / ’LLDT’ / ’LTR’ / ’LMSW’ ) –Cache-invalidates: ‘INVD’/‘INVLPG’/ WBINVD’ –‘CLTS’ or ‘HLT’

What happens if…? If protection rules are violated, or if errors result from computations, the processor will generate an ‘exception’ (i.e., it will save some information on the stack and transfer control to an ‘exception-handler’) Different kinds of exceptions will trigger different exception-handling procedures Gates in the IDT define the ‘entry-points’

Faults, traps, and aborts Intel classifies exceptions into categories, (according to whether or not it may be possible to ‘recover’ from the ‘error’): – ‘Faults’ are detected ‘before-the-fact’ (and generally indicate ‘recoverable’ errors) –‘Traps’ are detected ‘after-the-fact’ (and indicate some corrective action is needed) –‘Aborts’ are unrecoverable error-conditions

A ‘fault’ example Suppose an instruction tries to read from a ‘not-present’ data-segment: mov ax, [si] The CPU generate exception-number 0xB In case the corresponding IDT-descriptor is a 32-bit interrupt-gate (or trap-gate), the CPU will push at least four 32-bit values: –Current contents of the EFLAGS register –Current contents of registers CS and EIP –An ‘error-code’ (with info about DS register)

‘Fault’ example (continued) If it is necessary to switch stacks (due to a change in the exception-handler’s code-segment privilege-level), the ‘old’ stack’s address (i.e., registers SS and ESP) will also get pushed onto the ‘new’ stack The fault-handler can take whatever actions are necessary to resolve the ‘not-present’ condition, then mark the data-segment as being ‘present’ and ‘restart’ execution of the prior instruction

What about ‘not-present’ gates? If an exception is generated, but the IDT’s gate-descriptor for that type of exception isn’t ‘present’, then the CPU generates a General Protection exception (INT-0x0D) So by supplying one exception-handler for this ‘catch all’ exception, we can ‘service’ nearly all of the various error-conditions

Error-Code Formats The format of the error-code that the CPU pushes onto its stack depends upon which type of exception has been encountered For General Protection exceptions, the error-code format looks like this: segment selector index EXTEXT INTINT TITI TI=Table Indicator (0=GDT, 1=LDT) INT=Interrupt (1=yes, 0=no) EXT=External-to-CPU event was cause of the exception (1=yes, 0=no)

Stack Frame Layout (32bit) ESP EFLAGS EIP SS CS Error Code points to the faulting instruction points to the old stack’s top SS:ESP = the new stack’s top When the ‘fault’ exception uses a 32-bit Interrupt-Gate (or Trap-Gate)

Stack Frame Layout (16bit) SP FLAGS IP SS CS Error Code points to the faulting instruction points to the old stack’s top SS:SP = the new stack’s top When the ‘fault’ exception uses a 16-bit Interrupt-Gate (or Trap-Gate)

Catalog of x86 exceptions 0x00: divide-overflow fault 0x01: single-step trap or debug fault 0x02: non-maskable interrupt (NMI) trap 0x03: breakpoint trap 0x04: integer overflow trap 0x05: array bounds fault 0x06: invalid opcode fault 0x07: coprocessor unavailable fault

Catalog (continue) 0x08: double-fault abort 0x09: (reserved) 0x0A: invalid TSS fault/abort 0x0B: segment not present fault 0x0C: stack fault 0x0D: general protection exception fault 0x0E: page fault 0x0F: (reserved)

Catalog (continued again) 0x10: FPU floating-point error fault 0x11: operand alignment-check fault 0x12: machine-check exception abort 0x13: SIMD floating-point exception fault 0x14-0x1F: (reserved) 0x20-0xFF: (user-defined interrupts) NOTE: Only the following exceptions have error-codes: 0x8, 0xA, 0xB, 0xC, 0xD, 0xE

Demo program: ‘whycrash.s’ To illustrate the processor’s response to exceptions, we created this short demo It displays some diagnostic information (including the ‘error-code’) when the CPU triggers any exception-condition (all get routed through the IDT-gate for General Protection exceptions in this demo) Can help us identify causes for a ‘crash’

In-class exercise #1 Try experimenting with your own examples of impermissible instructions What if you try to store a value to the vram memory-segment using an address-offset larger than the 32KB segment-limit? What if you try to load a segment-register with a selector-value that exceeds the size of your descriptor-table? What if you try to ‘call’ to ring3 from ring0?

In-class exercise #2 If your ‘solution’ to midterm Question V caused a system-crash, can you find out why, by adding this exception-handler to your program’s source-text? Some useful programming techniques: –Using the as86 ‘INCLUDE’ directive (to include a separate source-text file –Using the as86 ‘-l’ command-line option (to generate an assembler ‘listing’ file)