I have been very strange to Int 2E in Ntdll, I can't use it in Ring 3? But NTDLL is not never neurred? When I use a program, Int 0x2e is really okay, no Error, INT 0x20 will be wrong, but the error is the case of the CPU. It is only displayed in the case, and then found it in the book (Linux book ...) Makes Sure the interrupt Was Issued by an authorized source. First, it compares the Current Privilege Level (CPL), which is stored in the two least significant bits of the cs register, with the Descriptor Privilege Level (DPL) of the Segment Descriptor included in the GDT. Raises a " General protection "exception if the CPL is lower than the DPL because the interrupt handler can not have a lower privilege than the program that caused the interrupt. For programmed exceptions, it makes a further security check. It compares the CPL with the DPL of the gate descriptor included in the IDT and raises a "General protection" exception if the DPL is lower than the CPL. this last check makes it possible to prevent access by user applications to specific trap or interrupt gates. The original understanding of this passage is always bad Now I understand, now the Windows program, all the use of Ring 3 is CS 001B, DS, ES 0023 The descriptor, and the core CS is 0008, so when INT 0x2e, the CPL = 3> DPL = 0, fixed is not line, then check the DPL = 3 of the DPL, 2E of the door descriptor, and int 0x2e can be performed, and see concrete may be better kd> pcrPCR Processor 0 @ ffdff000 NtTib.ExceptionList:! b96aac68 NtTib.StackBase: b96aadf0 NtTib.StackLimit: b96a8000 NtTib.SubSystemTib: 00000000 NtTib.Version: 00000000 NtTib. Userpointer: 00000000 NTTIB.SELFTIB: 7FFDE000
SelfPcr: ffdff000 Prcb: ffdff120 Irql: 00000000 IRR: 00000000 IDR: ffff24e0 InterruptMode: 00000000 IDT: 80036400 GDT: 80036000 TSS: 8028c000CurrentThread: fe8ec820 NextThread: 00000000 IdleThread: 8046c8c0
DPCQueue: Get the location of the IDT address 800364002e 80036400 2E * 8 = 80036570
kd> dd 8003657080036570 00083ea0 8046ee00 00086e40 80468e0080036580 00088128 80068e00 0008a3e4 817c8e0080036590 000834f4 80468e00 0008b844 817c8e00800365a0 0008bdc4 817c8e00 00083512 80468e00800365b0 0008351c 80468e00 00083526 80468e00800365c0 00082db0 80068e00 0008e044 81888e00800365d0 00083544 80468e00 0008da04 817c8e00
Sure enough segment: 0008 OFFSET 80463EA0 DPL 111 = 3
KD> LN 80463EA0 (80463EA0) NT! KISYSTEMSERVICE | (80463F75) NT! KiserviceExitexact Matches: NT! KisystemService =
The location of the IDT is constant in the system, at least I will restart or the same, the location of the IDT is in the IDTR register.
As mentioned in the earlier section Section 4.2.3, Intel provides three types of interrupt descriptors:.. Task, Interrupt, and Trap Gate Descriptors Task Gate Descriptors are irrelevant to Linux, but its Interrupt Descriptor Table contains several Interrupt and Trap Gate Descriptors Linux Classifies the as Follows, Using A Slightly DiffERENT BREAKDOWN AND TERMINOLOGY from Intel:
Interrupt gate An Intel interrupt gate that can not be accessed by a User Mode process (the gate's DPL field is equal to 0). All Linux interrupt handlers are activated by means of interrupt gates, and all are restricted to Kernel Mode.
System gate An Intel trap gate that can be accessed by a User Mode process (the gate's DPL field is equal to 3). The four Linux exception handlers associated with the vectors 3, 4, 5, and 128 are activated by means of system gates , so the four assembly language instructions int3, into, bound, and int $ 0x80 can be issued in User Mode.Trap gate An Intel trap gate that can not be accessed by a User Mode process (the gate's DPL field is equal to 0). Most Linux Exception Handlers Are ActiVated by Means of Trap Gates.
