Hubbry Logo
Interrupt descriptor tableInterrupt descriptor tableMain
Open search
Interrupt descriptor table
Community hub
Interrupt descriptor table
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Interrupt descriptor table
Interrupt descriptor table
Interrupt descriptor table
View on Wikipedia
from Wikipedia

The interrupt descriptor table (IDT) is a data structure used by the x86 architecture to implement an interrupt vector table. The IDT is used by the processor to determine the memory addresses of the handlers to be executed on interrupts and exceptions.

The details in the description below apply specifically to the x86 architecture. Other architectures have similar data structures, but may behave differently.

The IDT consists of 256 interrupt vectors and the use of the IDT is triggered by three types of events: processor exceptions, hardware interrupts, and software interrupts, which together are referred to as interrupts:

  • Processor exceptions generated by the CPU have fixed mapping to the first up to 32 interrupt vectors.[1] While 32 vectors (0x00-0x1f) are officially reserved (and many of them are used in newer processors), the original 8086 used only the first five (0-4) interrupt vectors and the IBM PC IDT layout did not respect the reserved range.
  • Hardware interrupt vector numbers correspond to the hardware IRQ numbers. The exact mapping depends on how the Programmable Interrupt Controller such as Intel 8259 is programmed.[2] While Intel documents IRQs 0-7 to be mapped to vectors 0x20-0x27, IBM PC and compatibles map them to 0x08-0x0F. IRQs 8-15 are usually mapped to vectors 0x70-0x77.
  • Software interrupt vector numbers are defined by the specific runtime environment, such as the IBM PC BIOS, DOS, or other operating systems. They are triggered by software using the INT instruction (either by applications, device drivers or even other interrupt handlers). For example, IBM PC BIOS provides video services at the vector 0x10, MS-DOS provides the DOS API at the vector 0x21, and Linux provides the syscall interface at the vector 0x80.

Real mode

[edit]

In real mode, the interrupt table is called IVT (interrupt vector table). Up to the 80286, the IVT always resided at the same location in memory, ranging from 0x0000 to 0x03ff, and consisted of 256 far pointers. Hardware interrupts may be mapped to any of the vectors by way of a programmable interrupt controller. On the 80286 and later, the size and locations of the IVT can be changed in the same way as it is done with the IDT (Interrupt descriptor table) in protected mode (i.e., via the LIDT (Load Interrupt Descriptor Table Register) instruction) though it does not change the format of it.[3]

BIOS interrupts

[edit]
Main article: BIOS interrupt call

The BIOS provides simple real-mode access to a subset of hardware facilities by registering interrupt handlers. They are invoked as software interrupts with the INT assembly instruction and the parameters are passed via registers. These interrupts are used for various tasks like detecting the system memory layout, configuring VGA output and modes, and accessing the disk early in the boot process.

Protected and long mode

[edit]

The IDT is an array of descriptors stored consecutively in memory and indexed by the vector number. It is not necessary to use all of the possible entries: it is sufficient to populate the table up to the highest interrupt vector used, and set the IDT length portion of the IDTR accordingly.

The IDTR register is used to store both the linear base address and the limit (length in bytes minus 1) of the IDT. When an interrupt occurs, the processor multiplies the interrupt vector by the entry size (8 for protected mode, 16 for long mode) and adds the result to the IDT base address.[4] If the address is inside the table, the DPL is checked and the interrupt is handled based on the gate type.

The descriptors may be either interrupt gates, trap gates or, for 32-bit protected mode only, task gates. Interrupt and trap gates point to a memory location containing code to execute by specifying both a segment (present in either the GDT or LDT) and an offset within that segment. The only difference between trap and interrupt gates is that interrupt gates will disable further processor handling of maskable hardware interrupts, making them suitable to handle hardware-generated interrupts (conversely, trap gates are useful for handling software interrupts and exceptions). A task gate will cause the currently active task-state segment to be switched, using the hardware task switch mechanism to effectively hand over use of the processor to another program, thread or process.

Common IDT layouts

[edit]

Protected-mode exceptions and interrupts

[edit]

In protected mode, the lowermost 32 interrupt vectors are reserved for CPU exceptions. Those are events which are trigerred in the CPU itself, instead of receiving interrupt from the outside hardware. However, some CPU exceptions, such as NMI or #MC, directly relate to events happening in other components of the computer.[5][6] Interrupt vectors 0x20 to 0xff (hexadecimal) are left free for developer's usage for external interrupts. Interrupts with numbers below 0x20 should not be assigned for external interrupts.

x86 Interrupt descriptor table items[7] [edit table]
Int. № Mnem. Type Err. code[a] Name Source
hex dec
0x00 0 #DE Fault[b] No Divide Error Integer divide instructions: DIV, IDIV and AAM.
0x01 1 #DB Trap/Fault[c] No Debug Exception Instruction, data, and I/O breakpoints; single-step; INT1/ICEBP instruction and others.
0x02 2 NMI[d] Interrupt No NMI Interrupt Nonmaskable external interrupt.
0x03 3 #BP Trap No Breakpoint INT3 instruction.
0x04 4 #OF Trap No Overflow INTO instruction.
0x05 5 #BR Fault[b] No BOUND Range Exceeded BOUND instruction. Can also be generated by the Intel MPX instructions BNDCL,BNDCU,BNDCN,BNDLDX and BNDSTX.
0x06 6 #UD Fault No Invalid Opcode (Undefined Opcode) UD instruction or reserved opcode.
0x07 7 #NM Fault No Device Not Available (No Math Coprocessor)
  • Any x87 instruction except WAIT/FWAIT when CR0.EM is set.
  • Any x87 or SIMD (MMX/SSE/AVX/AVX-512/AMX) instruction except WAIT/FWAIT when CR0.TS is set.
  • WAIT/FWAIT instruction when both CR0.TS and CR0.MP are set.
0x08 8 #DF Abort Yes (zero) Double Fault Any instruction that can generate an exception, an NMI, or an INTR.
0x09 9 #MP[e] Abort No Coprocessor Segment Overrun

(reserved on 486 and later)

x87 floating-point instruction with a memory operand when middle part of memory operand is in inaccessible memory.[9][10]

(80287/80387 only; Intel 80486 and later processors will instead generate #GP or #PF exceptions for such operands)

0x0A 10 #TS Fault Yes Invalid TSS Task switch or TSS access.
0x0B 11 #NP Fault Yes Segment Not Present Loading segment registers or accessing system segments.
0x0C 12 #SS Fault Yes Stack-Segment Fault Stack operations and SS register loads.
0x0D 13 #GP Fault Yes General Protection Any memory reference and other protection checks.
0x0E 14 #PF Fault Yes Page Fault Any memory reference.
0x0F 15 N/a Intel reserved. Do not use.
0x10 16 #MF Fault No x87 FPU Floating-Point Error (Math Fault) x87 FPU floating-point, WAIT/FWAIT or MMX instruction.[f][g]
0x11 17 #AC Fault Yes Alignment Check Misaligned memory access.

On some newer processors, #AC can also be generated by instructions that try to perform locked accesses on uncacheable memory.

0x12 18 #MC Abort/
Fault/
Interrupt[h] 		No Machine Check Hardware error.

Error information is provided by machine-check MSRs. The set of errors that can be detected and reported through the Machine Check mechanism, as well as the MSRs that can hold the error information, are processor model dependent.

0x13 19 #XM Fault No SIMD Floating-Point Exception SSE/SSE2/SSE3/AVX/AVX2/AVX-512 floating-point instructions.[i]
0x14 20 #VE Fault No Virtualization Exception EPT (Extended Page Table) violations (Intel VT-x guest only)
0x15 21 #CP Fault Yes Control Protection Exception When CET shadow stacks are enabled, the RET, IRET, RSTORSSP, and SETSSBSY instructions can generate this exception.

When CET indirect branch tracking is enabled, this exception can be generated due to a missing ENDBRANCH instruction at the target of an indirect call or jump.

0x16
⋮
0x1B 		22
⋮
27 		N/a Reserved for future use as CPU exception vectors.
0x1C 28 #HV Interrupt No Hypervisor Injection Exception Event injection from hypervisor to SNP guest (AMD SEV-SNP guest only)
0x1D 29 #VC Fault Yes VMM Communication Exception Virtual-machine exit events that require the VMM to inspect guest register state (AMD SEV-ES guest only)
0x1E 30 #SX Interrupt Yes Security Exception Security-sensitive event (AMD SVM VMM only)
0x1F 31 N/a Reserved for future use as CPU exception vector.
0x20
⋮
0xFF 		32
⋮
255 		N/a Interrupt No N/a External interrupts.
  1. ^ This column determines whether the interrupt pushes an exception code to the interrupt handler stack, or not. For some exceptions, this pushes only a zero number
  2. ^ a b The #DE (divide error) and #BR (bound range exceeded) are fault-type exceptions on 80286 and later processors; on earlier processors, they were traps.
  3. ^ The #DB exception may be either a trap or a fault exception depending on the condition that caused the exception. (E.g. instruction breakpoints are faults, while data breakpoints and single-steps are traps.) The condition that caused the #DB exception can be identified by inspecting the DR6 debug register.
  4. ^ The official Intel documentation does not assign an official mnemonic to this interrupt, but abbreviation “NMI” is widely used to refer to this interrupt, even in the Intel docs itself.
  5. ^ The #MP mnemonic for exception 9 is listed in Intel 80286 documentation only[8] − later Intel documentation for 80386 and later processors continues to describe this exception but no longer uses the #MP mnemonic for it.
  6. ^ When an unmasked math exception is detected in the x87 FPU, it is not signalled as a fault on the x87 instruction producing the exception, but instead on the next x87/FWAIT/MMX instruction.
  7. ^ On i486 and later processors, the #MF exception can only be signalled if the CR0.NE bit is set — if this bit is not set, then the CPU will instead assert the FERR# pin and wait for an external interrupt.

    On 80286 and 80386 processors, which don't have CR0.NE, the #MF exception vector is supported by the processor, but IBM-compatible PCs will reroute FPU error signals in such a way that x87 FPU errors show up as IRQ13 (INT 75h) instead.[11]
  8. ^ On x86 processors that support Machine Check Architecture (Intel Pentium Pro and later, AMD K7 and later), the #MC exception may act as either an Abort, Fault or Interrupt type exception depending on the type of error that caused the exception. This is indicated with the RIPV bit (bit 0) and EIPV bit (bit 1) of the MCG_STATUS MSR (MSR 17Ah):
    • The RIPV bit indicates whether the instruction stream can be restarted from the CS:rIP value pushed on the stack (1=yes, 0=no)
    • The EIPV bit indicates whether the error is associated with the instruction pointed to by the CS:rIP value pushed on the stack (1=yes, 0=no)
  9. ^ Unlike the #MF exception used for x87 errors, the #XM exception is signalled as a fault on the instruction that caused the SIMD floating-point exception.

IBM PC layout

[edit]

The IBM PC (BIOS and MS-DOS runtime) does not follow the official Intel layout beyond the first five exception vectors implemented in the original 8086. Interrupt 5 is already used for handling the Print Screen key, IRQ 0-7 is mapped to INT_NUM 0x08-0x0F, and BIOS is using most of the vectors in the 0x10-0x1F range as part of its API.[12]

Hooking

[edit]

Some Windows programs hook calls to the IDT. This involves writing a kernel mode driver that intercepts calls to the IDT and adds in its own processing. This has never been officially supported by Microsoft, but was not programmatically prevented on its operating systems until 64-bit versions of Windows, where a driver that attempts to use a kernel mode hook will cause the machine to bug check.[13]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Interrupt descriptor table

View on Grokipedia
from Grokipedia
The Interrupt Descriptor Table (IDT) was introduced with the microprocessor in 1982 to support interrupt handling. It is a system in the x86 architecture used by the processor to handle interrupts and exceptions, associating each of the 256 possible interrupt vectors (numbered 0 through 255) with a specific handler routine or task through descriptors that specify the segment selector, offset, and attributes for control transfer. In and IA-32e mode, the IDT resides in memory and is accessed via the IDTR register, which stores the table's base address and limit; it supports up to 256 entries of 8 bytes each (totaling 2 KB) in or 16 bytes each in 64-bit mode to accommodate 64-bit offsets. The IDT's primary purpose is to provide an efficient mechanism for the operating system to manage hardware interrupts (such as from devices), software interrupts (invoked via instructions like INT n), processor-detected exceptions (like page faults), and traps, enabling the processor to transfer control to the appropriate memory-resident procedure or task upon event occurrence. Vectors 0 through 31 are reserved for processor exceptions and non-maskable interrupts (NMI, at vector 2), while vectors 32 through 255 are available for maskable hardware interrupts, software interrupts, or use by the (APIC). The table must be initialized by the operating system using the LIDT instruction (requiring current privilege level 0) before interrupts are enabled, with empty or unused entries required to have the present (P) flag cleared to 0 to prevent general-protection exceptions (#GP) on invalid vector references. Each IDT entry is a gate descriptor, of which there are three types: interrupt gates, which transfer control to a handler and automatically clear the (IF) to disable further maskable interrupts; trap gates, which perform the transfer without affecting IF and are used for or certain exceptions; and task gates, which initiate a task switch via a Task State Segment (TSS) but are not supported in IA-32e mode. Descriptors include privilege controls via the descriptor privilege level (DPL) for checks, support for inter-privilege-level calls with stack switching, and alignment on an 8-byte boundary, with the limit set to 8N – 1 for N entries. In , a simpler (IVT) at physical address 0 is used for interrupt handling, while the IDT extends these capabilities in for segmented memory and larger address spaces.

Introduction

Definition and Purpose

The Interrupt Descriptor Table (IDT) is a system data structure in the x86 architecture, consisting of an array of up to 256 entries that map interrupt vectors numbered from 0 to 255 to corresponding gate descriptors. Each entry in the IDT defines the segment selector, offset, and attributes for an interrupt or exception handler procedure or task, allowing the processor to reference these descriptors during event processing. The table's location and size are specified by the Interrupt Descriptor Table Register (IDTR), which holds the base linear address and limit of the IDT. The primary purpose of the is to provide a mechanism for the processor to locate and invoke appropriate service routines in response to and exceptions, ensuring orderly handling of system events. It supports hardware interrupts from external devices, software interrupts initiated by the INT instruction, and processor-generated exceptions including faults, traps, and aborts. By associating each vector with a descriptor—such as an interrupt gate, trap gate, or task gate—the enables controlled transfers of execution while enforcing protection rules like privilege levels. In the x86 architecture, the IDT has been central to protected-mode interrupt handling since its introduction with the processor, where it superseded the simpler real-mode by incorporating segmented addressing and privilege checks. Upon occurrence of an or exception, the processor uses the event's vector number as an index into the IDT (multiplied by 8 to locate the entry), retrieves the associated descriptor, and transfers control to the specified handler or task accordingly. This process maintains system integrity by validating the descriptor's presence and attributes before execution.

Historical Context

The Interrupt Vector Table (IVT) originated with the microprocessor in 1978, serving as the foundational mechanism for interrupt handling in . It occupied a fixed region from 0x0000 to 0x03FF, comprising 256 entries of four bytes each—a 16-bit offset followed by a 16-bit selector—enabling direct jumps to interrupt service routines within the 1 MB . The Interrupt Descriptor Table (IDT) emerged with the in 1982, marking a pivotal shift to and addressing the IVT's limitations in supporting advanced operating system features. Unlike the IVT's static location, the IDT's base address and limit were managed dynamically via the IDTR register, with each of its 256 entries expanded to eight bytes to incorporate gate types (task, , and trap) and segment selectors, facilitating segmented memory addressing and privilege-level checks. This evolution was primarily driven by the demand for to isolate processes and prevent unauthorized access, as well as hardware-assisted multitasking to enable efficient context switching in multi-user environments, overcoming real mode's 1 MB address ceiling and lack of security mechanisms. Subsequent enhancements in the Intel 80386 (1985) solidified the IDT's role by fully supporting 256 vectors with refined trap and interrupt gates, accommodating 32-bit offsets for broader addressability and improved in segmented environments. The transition to via the AMD64 architecture in 2003 extended IDT entries to 16 bytes in , incorporating 64-bit offsets while restricting gate types to 64-bit interrupt and trap variants, thus enabling robust interrupt redirection and stack management for larger virtual address spaces. These developments were essential for modern operating systems such as and , which rely on the IDT for secure interrupt isolation and multitasking, while preserving real-mode IVT compatibility to support legacy BIOS and DOS applications.

IDT Structure

Overall Organization

The Interrupt Descriptor Table (IDT) is organized as a linear of up to 256 entries in , where each entry corresponds to an or exception vector and points to the of the associated handler routine. This structure allows the processor to quickly locate and invoke the appropriate service routine upon receiving an vector number. The table's fixed maximum size ensures efficient indexing without requiring dynamic allocation during processing. In , each IDT entry occupies 8 bytes, resulting in a maximum table size of 2 KB for 256 entries. In (IA-32e), entries are expanded to 16 bytes to support 64-bit addressing, yielding a maximum size of 4 KB. The operating system determines the actual number of populated entries, but the table is designed to accommodate the full range even if only a subset is used. The location and size of the are managed by the Interrupt Descriptor Table Register (IDTR), a dedicated that holds the linear base address of the table and its limit in bytes. In , the IDTR is a 48-bit structure (6 bytes total), comprising a 32-bit base address and a 16-bit limit field. In , it extends to 80 bits (10 bytes), with the base address widened to 64 bits while retaining the 16-bit limit. This register enables the processor to access the from any position in the linear . The processor indexes into the using an 8-bit vector number ranging from 0 to 255, which serves as the entry index and is scaled by the entry size (8 bytes in or 16 bytes in ) to compute the offset from the base address. This mechanism supports sparse population, where unused entries can be left undefined or marked to generate a trap if accessed, allowing flexible allocation without requiring contiguous filling of the table. The operating system allocates the IDT in kernel linear address space, typically placing it in a protected memory region to prevent user-mode access. The IDTR limit must be set to at least 255 bytes in protected mode (to cover the first 32 exception vectors, each 8 bytes) or 511 bytes in long mode (for 16-byte entries), though full population requires limits of 2047 bytes or 4095 bytes, respectively, to encompass all 256 entries.

Descriptor Format

Each entry in the Interrupt Descriptor Table (IDT) is a gate descriptor that specifies the location and type of handler for an interrupt or exception. In protected mode, these descriptors are 8 bytes long and consist of several key fields that define the handler's address, target segment, and access attributes. The protected mode descriptor format includes the following bit fields: bits 0-15 hold the low 16 bits of the handler offset; bits 16-31 contain the segment selector for the code segment containing the handler; bits 32-47 are reserved (must be zero for interrupt and trap gates); bits 48-51 specify the gate type (with values 14 for interrupt gates and 15 for trap gates); bit 52 is reserved (zero); bits 53-54 indicate the Descriptor Privilege Level (DPL); bit 55 is the Present (P) flag; and bits 56-63 hold the high 16 bits of the handler offset. For task gates (type 5), the segment selector points to a Task State Segment (TSS) instead of a code segment, and offset fields are reserved. In (IA-32e), descriptors are extended to 16 bytes to support 64-bit addressing and additional features. The layout builds on the format but includes: bits 0-15 for offset low (15:0); bits 16-31 for segment selector; bits 32-35 for the Interrupt Stack Table (IST) index (0-7, with 0 indicating no IST); bits 36-39 reserved (zero); bits 40-43 for type (14 for interrupt gate, 15 for trap gate); bit 44 reserved; bits 45-46 for DPL; bit 47 for P; bits 48-63 for offset middle (31:16); bits 64-95 for offset high (63:32); and bits 96-127 reserved (zero). Task gates are not supported in long mode. Gate types determine handler behavior: an interrupt gate (type 14) clears the Interrupt Flag (IF) in EFLAGS to disable maskable hardware interrupts during execution, suitable for hardware interrupts; a trap gate (type 15) preserves the IF flag, allowing nested interrupts and used for software exceptions or debugging; a task gate switches to a new task via the referenced TSS but is rarely used after the 80386 due to the deprecation of task management in modern systems. Attribute flags control validity and access: the P flag (bit 55 in , bit 47 in numbering) must be 1 for the descriptor to be valid, or a not-present (#NP) exception occurs; the DPL (bits 53-54 in , bits 45-46 in ) specifies the minimum privilege level (0 highest to 3 lowest) required for invocation, enforcing ring checks to prevent less-privileged code from triggering higher-privilege handlers. Invalid descriptors, such as those with P=0 (triggering #NP), non-zero reserved bits, or invalid types, trigger a general-protection (#GP) fault during interrupt dispatch for the latter cases. The full handler offset is assembled as (offset_high << 32 | offset_middle << 16 | offset_low) in or (offset_high << 16 | offset_low) in , forming the into the target .
FieldProtected Mode BitsLong Mode BitsDescription
Offset Low0-150-15Lower 16 bits of 32/64-bit handler address
Segment Selector16-3116-31Index into GDT/LDT for code/TSS segment
Reserved/IST32-47 (reserved=0)32-39 (IST index 0-7)Stack table index in ; reserved otherwise
Type48-51 (e.g., 14=0xE, 15=0xF, 5=0x5)40-43 (e.g., 14=0xE, 15=0xF, 9=0x9)Defines gate behavior (, trap, task)
DPL53-54 (0-3)45-46 (0-3)Privilege level for
P55471 if descriptor present
Offset High/Middle56-63 (31:16)48-63 (31:16), 64-95 (63:32)Upper bits of handler address
ReservedN/A (beyond 63)96-127 (=0)Must be zero for compatibility

Operating Modes

Real Mode

In real mode, the x86 architecture employs the (IVT) as the functional equivalent of the (IDT), providing a simple mechanism for interrupt handling without the segmentation or protection features of . The IVT is fixed at physical memory addresses 00000h to 003FFh, occupying the first 1 KB of RAM and consisting of 256 entries, each 4 bytes in length. Each entry comprises a 2-byte segment selector followed by a 2-byte offset, forming a far pointer to the routine in the 1 MB real-address space; unlike protected-mode descriptors, these entries do not include gates, selectors, or attribute fields such as type, privilege level, or present bit. The LIDT instruction, which loads the base address and limit into the IDT register (IDTR), behaves differently in compared to . In , the base address is ignored, as the IVT remains fixed at address 0, while the limit must be set to exactly 03FFh to match the 1 KB table size; any other limit value leads to during processing. When an occurs, the processor uses the vector number (0 to 255) to index the IVT—multiplying the vector by 4 to locate the entry—then fetches the segment:offset pair and transfers control directly to that address after pushing the current flags, code segment (CS), and instruction pointer (IP) onto the stack in 16-bit format. This direct jump lacks any validation, allowing interrupts to execute code anywhere within the 1 MB address space. Real mode imposes significant limitations on interrupt handling due to its simplified design. Without privilege levels or ring protections, any interrupt vector can access and potentially corrupt critical system areas, such as kernel code, if not properly handled, as there are no mechanisms to enforce access controls or stack switching. The addressing model is constrained to 20-bit physical addresses (up to 1 MB), with 16-bit offsets limiting handler reach without additional segmentation tricks, and no support for 32-bit code or data in standard configurations. These constraints make real mode suitable only for legacy or initialization environments. For compatibility with early x86 systems, the IVT is integral to bootloaders, which initialize vectors during (POST) to set up basic handlers before transitioning modes, and to , where applications hook IVT entries to extend functionality without kernel privileges. services, provided by in low memory (typically F0000h to FFFFFh), are invoked via software interrupts using the IVT; for example, accesses video services like mode setting or character output by vectoring to the BIOS handler at IVT offset 40h (10h * 4). This structure ensures for 16-bit code in environments like DOS but requires careful vector management to avoid conflicts.

Protected Mode

In protected mode, the interrupt descriptor table (IDT) consists of 256 entries, each 8 bytes in length, that define the location and access rights for and exception handlers. Each entry includes a 16-bit segment selector that references a descriptor in the (GDT) or local descriptor table (LDT), along with a 32-bit offset that specifies the of the handler within that segment, forming a linear as CS:EIP. The entries can be task gates, gates, or trap gates; and trap gates directly invoke the handler routine, while task gates trigger a task switch via a task state segment (TSS). This structure enables the processor to support segmented memory addressing, distinguishing protected mode from real mode's flat model. Privilege enforcement is integral to IDT operations in protected mode, where the descriptor privilege level (DPL) of a gate is compared against the current privilege level (CPL) of the interrupted task. For software interrupts (such as INT n or INT 3), a general protection fault (#GP) is generated if the CPL exceeds the DPL, preventing less privileged code from invoking higher-privilege handlers; however, this check is bypassed for hardware interrupts and processor exceptions to ensure reliable error handling. Interrupt gates additionally clear the interrupt flag (IF) in EFLAGS upon entry to mask further interrupts, whereas trap gates preserve IF to allow nested interrupts or traps. The segment selector undergoes standard checks for validity, including conforming or non-conforming code segment rules, to maintain isolation between privilege rings. When an or exception occurs, the processor saves the current state on the stack, pushing EFLAGS, CS, and EIP; if a privilege-level change is required, it also pushes SS and ESP from the appropriate TSS stack pointer. The handler is then loaded by combining the segment selector and offset from the IDT entry, with the processor switching stacks if entering a more privileged level to isolate execution contexts. Certain exceptions (vectors 0 through 31) may push an error code immediately after EIP for diagnostic purposes, such as segment faults. Execution returns via the IRET instruction, which restores the , including EFLAGS, while re-enabling interrupts only if the original IF was set (for interrupt gates, this occurs after the handler clears the mask if needed). These mechanisms provide multitasking isolation and protection not available in , with vectors 0-31 reserved exclusively for processor-defined exceptions to enforce integrity.

Long Mode

In , the Interrupt Descriptor Table (IDT) supports 64-bit operation within the architecture, utilizing 16-byte descriptors to handle and exceptions across the full 64-bit linear . Each descriptor includes a 64-bit offset to the handler code with bits 15:0 in bytes 0–1, bits 31:16 in bytes 6–7, and bits 63:32 in bytes 8–11, along with a 16-bit code-segment selector, a 3-bit Interrupt Stack Table (IST) index, and attribute fields specifying the gate type ( or trap), descriptor privilege level (DPL, 2 bits), and present bit. This format enables a flat memory model without code-segment base addresses, differing from segmented addressing in 32-bit , and eliminates support for task gates to streamline hardware behavior. The IST field provides a mechanism for automatic stack switching during interrupt delivery, referencing one of up to seven 64-bit stack pointers stored in the Task State Segment (TSS); an IST index of zero uses the current stack, while non-zero values load a dedicated kernel stack to prevent overflows from nested or exceptions, such as double faults or machine checks. Interrupt gates clear the IF flag in RFLAGS upon entry to disable further maskable during handler execution, ensuring atomicity, while trap gates leave IF unchanged to allow nesting. The 256 vectors (0-255) align with protected mode assignments but generate #SS stack faults for invalid stack conditions in 64-bit contexts. Handlers execute in 64-bit code segments (with CS.L=1 and CS.D=0), typically using a fixed kernel code selector like 0x08, and the processor pushes an 8-byte stack frame comprising SS, RSP, RFLAGS, CS, and RIP unconditionally upon entry. Returning from handlers employs the IRETQ instruction, which pops the stack frame in reverse order—RIP, CS, RFLAGS, RSP, SS—restoring the 64-bit processor state and re-enabling interrupts if the saved RFLAGS.IF was set. If the return targets compatibility mode (a 32-bit code segment with CS.L=0), the handler can invoke legacy 32-bit code, maintaining backward compatibility for mixed environments, though all IDT entries must use 64-bit offsets in canonical form to avoid general-protection faults. In operating systems such as 64-bit Linux and Windows, the IDT emphasizes IST usage for reliable nesting; for instance, Linux configures IST entries in the TSS for vectors like 8 (double fault) and 2 (NMI) to switch to per-CPU emergency stacks, while Windows employs similar mechanisms in its kernel for exception handling without task-state segment switches.

Setup and Initialization

Loading the IDT

The loading of the Interrupt Descriptor Table (IDT) into the processor's Interrupt Descriptor Table Register (IDTR) is a critical step performed by the operating system kernel during early initialization, typically after the (GDT) has been established. This process establishes the location and size of the IDT in memory, enabling the CPU to reference it for and in . The IDTR, a special register, holds the linear base address of the IDT and its limit (the size minus one). The LIDT (Load Interrupt Descriptor Table) instruction is used exclusively for this purpose, with the syntax LIDT [memory operand], where the operand is a 6-byte in the format specified by the : the first word (16 bits) contains the limit, followed by the base (32 bits in IA-32 mode or 64 bits in ). The instruction loads these values directly into the IDTR without segment translation, making it one of the few operations that handle linear addresses in . For a complete IDT supporting 256 vectors, the limit is set to 0x7FF (2047 bytes) in IA-32 , where each descriptor is 8 bytes (256 × 8 = 2048 bytes total), or 0xFFF (4095 bytes) in , where descriptors are 16 bytes each. In , the IDT is not used; instead, the fixed (IVT) at 0x00000000 handles interrupts, and the LIDT instruction primarily serves to load the limit value, with the base being ignored by the processor. No explicit LIDT execution is required for basic real-mode operation beyond verifying the limit, but it may be invoked during the transition to . A typical initialization sequence in the kernel involves allocating a contiguous block of kernel-accessible for the , zero-initializing the entries to prevent , computing the IDTR values (e.g., base as the linear of the allocated and limit as 0xFFF for a full table in ), and then issuing the LIDT instruction to load them. This occurs very early in the boot process, often within the initial kernel , to ensure interrupts are properly vectored before enabling additional hardware or user code. For example, in assembly or inline code, an pointer structure is prepared and passed to LIDT as follows:

lidt [idtr_ptr]

lidt [idtr_ptr]

where idtr_ptr points to the 6-byte (or 10-byte in 64-bit mode) descriptor. If the limit is invalid (e.g., zero or exceeding mode-specific maxima), the LIDT instruction triggers a general protection exception (#GP) immediately. In , the base address should ideally be page-aligned (multiples of 4096 bytes) to optimize with paging enabled, though the CPU does not enforce this alignment strictly. Execution of LIDT requires kernel privilege level (CPL=0); otherwise, it raises #GP.

Configuring Descriptors

Configuring an IDT descriptor involves populating its fields to define the interrupt handler's location, privilege level, and behavior, typically after the IDT has been allocated and loaded into the IDTR. For a standard 32-bit interrupt gate, the offset field is set to the linear address of the handler routine, the selector field points to the kernel code segment (e.g., index 8 in the GDT, yielding selector 0x08), the type field is configured as 0x8E (indicating a 32-bit interrupt gate with present bit set, DPL=0 for kernel-only access, and interrupt flag clearing), and the present bit is asserted to 1. This assembly ensures the processor clears the (IF) upon entry, preventing nested interrupts unless explicitly re-enabled. In operating systems like , descriptors are configured using kernel functions such as set_intr_gate, which initializes the entry with the handler address, kernel code selector (__KERNEL_CS), type 14 (GATE_INTERRUPT, corresponding to 0x8E in the low byte with DPL=0 and present=1), and DPL=0 for ring 0 access. Inline assembly can also be used to directly write the 8-byte descriptor structure into , packing the offset into bits 15-0 and 47-32, selector into bits 55-40, and attributes (including type 0x8E) into bits 39-32 and 63-56. In (64-bit), descriptors expand to 16 bytes, with the offset becoming a full 64-bit value split across the structure, and an additional 3-bit IST (Interrupt Stack Table) index field (bits 31-0 of the high doubleword) specifying an entry in the TSS for stack switching on critical like NMIs. employs variants like set_nmi_gate with ISTG macros to set this index (e.g., IST_INDEX_NMI) for vectors requiring isolated stacks. Validation of configured descriptors includes verifying the present bit is set to 1 (otherwise triggering a #NP exception), confirming the selector indexes a valid executable code segment in the GDT with conforming access rights, and ensuring the DPL matches the intended privilege (e.g., 0 for kernel handlers). In , the offset must form a canonical address to avoid #GP faults. Functionality can be tested by issuing CLI (clear IF) and STI (set IF) instructions around handler invocations to observe masking behavior, confirming the gate type's effect on the . Dynamic updates to individual descriptors require kernel privilege (CPL=0) and involve first using the SIDT instruction to store the IDTR contents, retrieving the base address of the . The target entry's memory location is then computed as base + (vector_number × entry_size), where entry_size is 8 bytes in 32-bit modes or 16 bytes in , allowing direct overwrite of the descriptor fields with new values. Post-update, the processor automatically uses the modified entry on the next without requiring IDTR reload, though atomicity must be ensured to avoid partial reads during handler dispatch.

Interrupt Vectors and Assignments

Exceptions

The Interrupt Descriptor Table (IDT) reserves the first 32 vectors (0 through 31, or 0h to 1Fh) for processor exceptions and the (NMI at vector 2) in x86 architectures. These include synchronous events triggered by the CPU itself during instruction execution or due to internal errors. These exceptions are categorized into three types: faults, traps, and aborts, each with distinct handling behaviors to maintain system integrity. Faults occur before the completion of the faulting instruction and are restartable, allowing the processor to resume execution from the original instruction pointer after the handler returns; examples include the divide error (#DE, vector 0) and (#PF, vector 14). Traps, in contrast, are reported after the trapping instruction completes, enabling execution to continue at the subsequent instruction without restart; representative cases are the exception (#BP, vector 3) and overflow (#OF, vector 4). Aborts represent severe, often unrecoverable conditions where program state may be lost and restart is impossible, such as the (#MC, vector 18) or double fault (#DF, vector 8). Certain exceptions push a 32-bit error code onto the stack immediately after the return address, providing diagnostic information to the handler; this applies to vectors like #TS (10, invalid TSS), #NP (11, segment not present), #SS (12, stack segment fault), #GP (13, general protection), #PF (14, page fault), and #AC (17, alignment check). For the page fault (#PF), the error code encodes bits indicating whether the fault was due to a present/not-present page (P), read/write access (W/R), user/supervisor mode (U/S), and other attributes like instruction fetch (I) or protection key (PK); additionally, the processor loads the faulting linear address into the CR2 register for handler use, though CR2 is not pushed onto the stack. Not all exceptions generate error codes—for instance, #DE (vector 0) and #BP (vector 3) do not—requiring handlers to infer causes from context or registers. The double fault exception (#DF, vector 8) is unique as an abort triggered by a second exception (often a contributory fault or page fault) during the handling of a prior one; it pushes an error code of 0 and uses a dedicated double-fault stack (via the task state segment) to avoid recursion, but if unhandled, it escalates to a triple fault, invoking a processor reset or shutdown. Operating systems must install valid descriptors (typically or trap gates) for all vectors 0-31 to ensure reliable , as failure to do so risks unrecoverable triple faults and system instability. In practice, modern OS kernels like implement comprehensive exception tables—arrays mapping faulting instruction addresses to fixup code—that allow handlers (e.g., for #PF) to search for and execute recovery routines, such as returning -EFAULT for invalid user-space accesses, thereby emulating safe fault resolution without full restarts. This setup prioritizes precise exception classification and minimal disruption, with trap gates used for debug-oriented traps like #BP to preserve flags.

Hardware Interrupts

Hardware interrupts, also known as external interrupts, are asynchronous signals generated by hardware devices to request service from the CPU, with the Interrupt Descriptor Table (IDT) providing the entry points for their handlers via specific vectors. In systems using the legacy 8259 (PIC), interrupt requests (IRQs) from devices are prioritized and remapped to IDT vectors in the range 0x20 to 0x2F to avoid overlap with exception vectors (0x00 to 0x1F). The master PIC handles IRQs 0-7, mapping them to vectors 0x20-0x27, while the slave PIC manages IRQs 8-15, mapping to 0x28-0x2F, with the slave cascaded through the master's IRQ 2. In modern systems employing the (APIC) or its extensions like x2APIC, hardware interrupts use vectors starting from 0x30 for local APIC interrupts, with the full range extending up to 0xFF (255 vectors total) for greater flexibility and scalability. The I/O APIC routes device IRQs to these vectors, while the local APIC handles internal events, allowing programmable assignment beyond the fixed PIC scheme. The handling process begins when a device asserts its IRQ line, prompting the PIC or APIC to prioritize the request and deliver the corresponding vector number to the CPU via the APIC interface or INTA cycle. The CPU then uses this vector as an index into the to locate and invoke the interrupt gate or task gate descriptor, transferring control to the handler routine. Upon completion, the handler issues an End-of-Interrupt (EOI) command to the controller—via port 0x20 for the master PIC, 0xA0 for the slave, or the APIC's EOI register—to clear the and re-enable the line for future events. Priority management ensures orderly handling: in the 8259 PIC, priorities are fixed in hardware with IRQ 0 (typically the system timer) as the highest and IRQ 7 as the lowest, resolved by a daisy-chain mechanism if multiple IRQs are pending. The APIC, in contrast, supports programmable priorities through registers like the Task Priority Register (TPR), allowing software to adjust levels dynamically for better control in multiprocessor environments. Interrupt nesting is facilitated by interrupt gates, which automatically clear the Interrupt Flag (IF) in the EFLAGS register to disable maskable interrupts during handler execution, preventing lower-priority interruptions until the handler re-enables IF or issues EOI. Representative examples include the system timer on IRQ 0, mapped to vector 0x20 in PIC systems or a programmable vector like 0x31 in APIC configurations for periodic timing events, and the keyboard controller on IRQ 1, using vector 0x21 or 0x32 to signal key presses. These mappings ensure that critical hardware events, such as timing and input, integrate seamlessly with the IDT for efficient CPU response.

Software Interrupts

Software interrupts in the x86 architecture are explicitly generated by software instructions to invoke handlers defined in the (IDT), allowing controlled transitions to privileged code such as operating system services. The primary mechanism is the INT n instruction, where n is an 8-bit immediate value specifying the interrupt vector (0 to 255), which serves as an index into the to locate the corresponding gate descriptor. Upon execution, the processor pushes the current values of the EFLAGS register (including the direction flag for string operations), the selector (CS), and the instruction pointer (EIP or RIP) onto the stack; if the interrupt causes a privilege-level change (e.g., from user to kernel mode), it additionally pushes the stack segment selector (SS) and stack pointer (ESP or RSP) before the others. The processor then loads the handler's and offset from the IDT entry and jumps to it, with the saved CS:EIP/RIP pointing to the instruction immediately following the INT n. A specialized form is the INT 3 instruction (opcode 0xCC), a one-byte breakpoint interrupt that generates vector 3 to invoke a debug handler, commonly used for software breakpoints in debugging tools without requiring hardware support. Unlike general INT n, INT 3 is treated as a trap-class event, allowing single-stepping through the breakpoint itself if desired. To return from a software interrupt handler, the IRET (or IRETQ in 64-bit mode) instruction pops the stack in reverse order—restoring EIP/RIP, CS, EFLAGS (which reinstates the original direction flag, preserving its state for instructions like string moves), and if applicable, SS and ESP/RSP—thus returning control to the interrupted code while maintaining processor state integrity. Historically, software interrupts have been widely used for operating system interactions, such as system calls in legacy environments. In , the INT 21h (vector 0x21) provided a multipurpose interface for services like file I/O, program execution, and keyboard input, with the AH register specifying the subfunction. Similarly, early kernels on 32-bit x86 employed INT 0x80 (vector 128) as the primary syscall , where the syscall number in EAX selected the kernel routine, passing arguments via registers; this legacy path remains supported for compatibility in modern kernels via the entry_INT80_compat handler. Vectors from 0x80 (128) to 0xFF (255) are typically reserved for user-defined software interrupts, as lower vectors (0-31) are dedicated to processor exceptions and non-maskable interrupts. In contemporary systems, however, the INT instruction for syscalls has been largely deprecated in favor of dedicated instructions like SYSCALL and SYSRET in 64-bit , which offer faster context switching by avoiding full IDT gate traversals and stack manipulations for privilege changes, reducing latency in high-frequency operations. These modern alternatives, introduced with AMD64 extensions and adopted by , bypass the overhead of interrupt gates (often configured as trap gates for software events) while maintaining security through model-specific registers for kernel entry points. INT remains relevant for (e.g., INT 3) and legacy compatibility but is avoided in performance-critical paths due to its slower entry and exit compared to SYSCALL.

Common Layouts and Examples

Standard x86 Layout

The standard x86 layout for the (IDT) follows 's recommended assignments for the 256 available interrupt vectors, reserving the lowest numbers for processor exceptions to ensure priority handling of critical events. Vectors 0 through 31 are dedicated to exceptions, such as vector 0 for the #DE (divide error) exception triggered by or overflow, and vector 14 for the #PF () exception occurring on invalid memory access. Vectors 32 through 47 ( 20h to 2Fh) are assigned to hardware interrupts from the legacy (PIC), mapping IRQ lines 0 through 15; for instance, vector 32 corresponds to IRQ0, typically handled by the system timer to avoid conflicts in multi-vendor hardware environments. The remaining vectors 48 through 255 are available for operating system-defined interrupts or device-specific uses, providing extensibility for modern systems. This layout is summarized in the following table:
Vector RangePurposeExamples/Notes
0–31Processor exceptions0: #DE (divide error); 14: #PF (page fault)
32–47 (20h–2Fh)Hardware interrupts (PIC IRQs)32 (IRQ0): System timer handler
48–255OS/device-defined interruptsAvailable for custom assignments
The rationale for this assignment prioritizes low vectors for exceptions to prevent overlap with software or hardware interrupts, enabling efficient prioritization and orderly handling across processor-detected events and external sources. Higher vectors support extensibility, accommodating growth in interrupt sources without disrupting core functionality. In variations from the basic PIC-based layout, the (APIC) architecture utilizes vectors 16 through 255 for inter-processor interrupts (IPIs), delivered via the Interrupt Command Register in fixed or NMI modes to facilitate multi-core communication. Message-signaled interrupts (MSIs), common in PCI devices, are programmable within vectors 48 through 255 (often 010h to 0FEh), using memory writes for interrupt signaling to enhance scalability in high-performance systems.

IBM PC Specifics

In the original IBM PC (Model 5150), a single 8259 (PIC) was employed, mapping its eight interrupt requests (IRQs 0 through 7) to interrupt vectors 08h through 0Fh in the (IVT). This configuration directly overlapped with the lower range of x86 processor exceptions (00h through 1Fh), creating potential conflicts since exceptions like double fault (08h) and coprocessor segment overrun (0Dh) shared the same vectors. To mitigate this in operating systems transitioning to , the PIC interrupts are typically remapped by the OS during initialization: IRQs 0-7 to vectors 20h-27h and, for systems with a second PIC, IRQs 8-15 to 28h-2Fh, preserving the exception space. This initial mapping led to legacy conflicts in PC-compatible systems, where vectors 08h-0Fh were dedicated to the original 8259 PIC hardware interrupts, while the reserved vectors 10h-1Fh for essential ROM routines, such as video services (10h) and disk I/O (13h). Specific examples include IRQ4 for asynchronous communications (e.g., COM ports) initially assigned to vector 0Ch, IRQ6 for the controller at 0Eh, and IRQ7 for the parallel printer at 0Fh, all of which could interfere with if not managed. Modern operating systems maintain compatibility mode support for DOS applications by preserving these original vector assignments in or through emulation, ensuring legacy software can invoke hardware interrupts without modification. The evolution to the IBM PC AT (Model 5170) introduced a second cascaded 8259A PIC as a slave controller connected via the master's IRQ2 (vector 0Ah), expanding to 16 IRQs while addressing the limitations of the single-PIC design. Initially, the slave PIC's IRQs 8-15 were mapped by the to vectors 70h-77h to avoid overlap with the BIOS-reserved 10h-1Fh range and potential conflicts in lower vectors, with examples including IRQ8 for the (RTC) at 70h and IRQ14 for the fixed disk controller at 76h. Operating systems subsequently remap the master to 20h-27h and the slave to 28h-2Fh for standardized protected-mode operation, shifting from the AT's initial high-vector placement while retaining .

BIOS Interrupts

In the x86 architecture's environment, interrupts provide a standardized interface for software to access low-level hardware services during system initialization and early operation. These software interrupts utilize vectors in the range of 10h to 1Fh, which are reserved specifically for functions, allowing programs to invoke routines without direct hardware manipulation. For instance, vector 10h handles video services, 13h manages disk operations, and 16h processes keyboard input, enabling essential tasks like displaying output or reading storage devices in the absence of a full operating system. These interrupts operate exclusively in real mode, where the interrupt vector table (IVT) at memory address 00000h points to handler code stored in read-only memory (ROM) segments starting from F0000h. Parameters are passed via CPU registers, with the AH register typically specifying the sub-function or service code; other registers like AL, BX, CX, and DX carry additional data or receive outputs. A representative example is INT 10h with AH=0Eh, which performs teletype output by writing the character in AL to the active display page, advancing the cursor, and interpreting control codes such as carriage return (CR) or line feed (LF), with BH selecting the page and BL the foreground color in graphics modes. This mechanism ensures compatibility across IBM PC-compatible systems by abstracting hardware variations through firmware. BIOS interrupts are inherently limited by real mode constraints, capping addressable memory at 1 MB and restricting access to 16-bit segmented addressing, which becomes inadequate for modern multitasking or large memory environments. Upon transitioning to , operating systems replace these interrupts with their own drivers and APIs, as the supersedes the IVT and BIOS services are no longer directly invocable without mode switches, which are inefficient and insecure. As a legacy component, BIOS interrupts remain relevant in the boot process, where the firmware uses them to perform power-on self-test (POST), initialize hardware, and load the bootloader via INT 19h before handing control to the OS. In contemporary systems adopting UEFI, this reliance diminishes, as UEFI boot services (e.g., EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL for video akin to INT 10h, EFI_BLOCK_IO_PROTOCOL for disk like INT 13h, and EFI_SIMPLE_TEXT_INPUT_PROTOCOL for keyboard like INT 16h) and runtime services provide equivalent functionality through protocol-based calls, eliminating the need for interrupt vectors in favor of a modular, 64-bit capable interface.

Advanced Usage

Interrupt Hooking

Interrupt hooking refers to techniques employed by kernel-level software, such as drivers or rootkits, to intercept and redirect processing defined in the (IDT). This allows custom code to execute before or instead of the original handler, enabling monitoring, modification, or suppression of -related events. In x86 architectures, typically involves modifying IDT entries to point to new interrupt service routines (ISRs), often while preserving the original functionality through chaining mechanisms. Kernel drivers achieve this by first locating the IDT using the SIDT instruction, which stores the table's base address in the IDTR register. The driver then overwrites the relevant entry—typically an 8-byte gate descriptor on x86-32 or 16-byte on —by updating the offset fields to the address of a custom handler. For example, the low and high offset components are set to form the new ISR address, while preserving the segment selector and attributes for privilege level and type (e.g., interrupt or trap gate). To chain to the original handler and avoid breaking system behavior, the custom ISR saves the context, performs its logic (such as logging or filtering), and jumps or calls the original routine before returning. This is common for IRQ filters, where the hook inspects interrupt sources before dispatching. In , loadable kernel modules (LKMs) facilitate such modifications directly in kernel space. On Windows, direct IDT hooking targets hardware interrupts, such as INT 0x2E for calls, by altering IDT pointers to malicious or custom ISRs, often requiring per-processor updates since each CPU maintains its own IDT. However, for syscall interception, developers more commonly the System Service Dispatch Table (SSDT), accessed via the kernel variable KeServiceDescriptorTable, which maps syscall indices to handlers after the initial (e.g., via SYSENTER or SYSCALL instructions). This indirect approach modifies the dispatch table in to redirect specific services like NtQueryDirectoryFile, allowing result filtering without altering the IDT itself. SSDT requires disabling in the CR0 register or using memory descriptor lists (MDLs) to map pages writable. These methods carry significant risks, including system instability from improper context handling, such as stack corruption or deadlocks during nested interrupts, potentially leading to kernel panics. In 64-bit Windows, (PatchGuard) actively scans for modifications and other kernel alterations, invoking a (BSOD) upon detection to enforce integrity. Alternatives to direct IDT hooking include virtualization-based interception, where a virtual machine monitor (VMM) using VT-x (VMX) controls interrupt delivery. In VMX mode, the VMM configures VM-execution controls like "external-interrupt exiting" to cause VM exits on , allowing it to inspect and redirect them before injecting virtual via the guest's IDT. For instance, employs VMX to emulate and intercept guest , enabling transparent without kernel modifications in the guest OS. User-mode alternatives rely on OS APIs for event monitoring, such as Windows' registered I/O completion ports, but cannot directly access the IDT due to privilege restrictions.

Security Considerations

The Interrupt Descriptor Table (IDT) is a critical kernel that can be targeted by , particularly rootkits, through overwrite techniques to intercept and gain unauthorized control over system execution. Rootkits often modify IDT entries to redirect interrupt handlers, enabling persistent kernel-level persistence and evasion of detection mechanisms. Such modifications can elevate attacker privileges by hijacking software interrupts, like system calls, without triggering general protection faults. In historical kernels (pre-3.8.9), techniques like CVE-2013-2094 exploited buffer overflows to alter IDT entries, including DPL fields, for ; these have been patched since 2013. Recent research as of 2025 has demonstrated novel hijacking techniques in modern kernels, even with SMEP and enabled. By exploiting LIDT instruction gadgets, attackers can relocate the to user-controlled memory, enabling (ROP) chains via exception redirection or causing denial-of-service (DoS) through unhandled faults. Proposed mitigations include enforcing constant virtual addresses for the with post-LIDT validation checks. To mitigate IDT manipulation, operating systems employ mechanisms, such as marking the pages as read-only in the kernel's page tables after initialization, preventing unauthorized writes from kernel-mode code or loaded modules. In , the is protected with read-only mappings and a fixed virtual address alias to prevent leakage of kernel addresses via SIDT, in conjunction with kernel (KASLR) that randomizes surrounding kernel space. Hardware features like Supervisor Mode Execution Prevention (SMEP) and (SMAP), introduced in processors, further protect against IDT-related risks by blocking kernel execution of user-mode code or access to user-mode memory, even if an attacker redirects an IDT entry to malicious payloads. In virtualized environments, hypervisors maintain a shadowed for guest virtual machines (VMs), allowing the host to intercept and validate deliveries without exposing the guest's to direct modification. Modern operating systems incorporate runtime integrity checks for the IDT. In Windows, (KPP), also known as PatchGuard, periodically scans the IDT for unauthorized modifications, such as altered gate descriptors or handler addresses, and triggers a halt if tampering is detected. For Linux, the IDT is locked into read-only pages during kernel initialization (), with subsequent protections enforced via module signing and modes to block unsigned kernel modules from accessing or altering it. Best practices for IDT security emphasize rigorous validation during setup and runtime. Kernel developers should verify segment selectors and DPL values in each IDT entry against expected kernel code segments (e.g., ensuring DPL=0 for most exceptions to restrict user invocation), using automated checks in initialization routines to detect misconfigurations. Additionally, utilizing the Interrupt Stack Table (IST) entries in the Task State Segment (TSS) isolates kernel interrupt stacks from user-mode faults; for example, assigning a dedicated IST for double faults or page faults prevents user-induced stack corruption from propagating to kernel execution, enhancing fault isolation.

References

  1. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
  2. http://bitsavers.trailing-edge.com/components/intel/80286/210498-005_80286_and_80287_Programmers_Reference_Manual_1987.pdf
  3. https://cdrdv2-public.intel.com/843836/325384-sdm-vol-3abcd-dec-24.pdf
  4. https://os.inf.tu-dresden.de/Studium/OSC/SS2024/L06-x86-64.pdf
  5. https://www.cs.wm.edu/~smherwig/readings/manuals/amd/sdm/amd64_arch_programmers_manual-vol2-system_programming.pdf
  6. https://cdrdv2-public.intel.com/671447/325384-sdm-vol-3abcd.pdf
  7. https://www.infosecinstitute.com/resources/reverse-engineering/msdos-and-the-interrupt-vector-table-ivt/
  8. https://bitsavers.org/pdf/ibm/pc/ps2/15F0306_PS2_and_PC_BIOS_Interface_Technical_Reference_May88.pdf
  9. https://www.felixcloutier.com/x86/lgdt:lidt
  10. https://docs.rtems.org/docs/6.1/cpu-supplement/intel_amd_x86.html
  11. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2a-manual.pdf
  12. https://c9x.me/x86/html/file_module_x86_id_156.html
  13. http://www.osdever.net/bkerndev/Docs/idt.htm
  14. https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/idt.c
  15. https://www.kernel.org/doc/html/next/x86/exception-tables.html
  16. https://cdrdv2-public.intel.com/671190/253668-sdm-vol-3a.pdf
  17. https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063
  18. https://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf
  19. https://wiki.osdev.org/8259_PIC
  20. https://minuszerodegrees.net/manuals/IBM_5170_Technical_Reference_6280070_SEP85.pdf
  21. http://bitsavers.trailing-edge.com/pdf/ibm/pc/ps2/PS2_and_PC_BIOS_Interface_Technical_Reference_Apr87.pdf
  22. https://ia801904.us.archive.org/6/items/System_BIOS_for_IBM_PC_XT_AT_Computers_and_Compatibles/System_BIOS_for_IBM_PC_XT_AT_Computers_and_Compatibles.pdf
  23. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf
  24. https://phrack.org/issues/59/4
  25. https://www.cs.wcupa.edu/SCHEN/malware2022/slides/ch14.pdf
  26. https://www.nccgroup.com/media/efmfyd35/_attacking_the_windows_kernel.pdf
  27. https://www.fortinet.com/blog/threat-research/melting-down-patchguard-leveraging-kpi-to-bypass-kernel-patch-protection
  28. https://www.cs.utexas.edu/~witchel/380L/papers/uhlig05ieeecomputer-intel_virtualization_technology.pdf
  29. https://inria.hal.science/hal-01460630v1/file/978-3-642-41148-9_21_Chapter.pdf
  30. https://www.infopoint-security.de/open_downloads/alt/McAfee_Whitepaper_rootkits_part_II.pdf
  31. https://rdomanski.github.io/Kernel-IDT-priviledge-escalation/
  32. https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-1351-miller.pdf
  33. https://lwn.net/Articles/569635/
  34. https://www.seandeaton.com/smep/
  35. https://cacm.acm.org/research/bare-metal-performance-for-virtual-machines-with-exitless-interrupts/
  36. https://blog.tetrane.com/downloads/Tetrane_PatchGuard_Analysis_RS4_v1.01.pdf
  37. https://alessandropellegrini.it/publications/tStro12.pdf
  38. https://www.kernel.org/doc/html/next/x86/pti.html
  39. https://www.kernel.org/doc/Documentation/x86/kernel-stacks
Add your contribution
Related Hubs
User Avatar
No comments yet.