Int 2E in Kernel

It has always been quite strange why the int 2E in Ntdll entered the kernel. Isn't it that the interrupt cannot be used under Ring 3? But this way NTDLL will not be in progress? If you try it with a program, int 0x2e is okay. No error occurs. Int 0x20 will cause an error, but the specific error is about the CPU, I used sice to show the error and 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 defined in the gdt. raises a "general protection" exception if the CPL is lower than the DPL because the interrupt handler cannot 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 encoded 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.
It turns out that this section is always hard to understand. Now, Windows programs and ring 3 use all the descriptors of CS 001b, DS, and ES 0023, the CS in the kernel is 0008. Therefore, when int 0x2e is used, CPL = 3> DPL = 0, which is not fixed. Then, check the DPL of the gate descriptor, 2e descriptor DPL = 3, so int 0x2e can be executed. It may be better to see the details.
Kd>! PCR
PCR 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: 8028c000

Currentthread: fe8ec820
Nextthread: 00000000
Idlethread: 8046c8c0

Dpcqueue:
Obtain the IDT address 80036400.
2e location: 80036400 + 2e * 8 = 80036570

Kd> dd 80036570
80036570 00083ea0 8046ee00 00086e40 80468e00
80036580 00088128 80068e00 0008a3e4 817c8e00
80036590 000834f4 80468e00 0008b844 817c8e00
800365a0 0008bdc4 817c8e00 00083512 80468e00
800365b0 0008351c 80468e00 00083526 80468e00
800365c0 00082db0 80068e00 0008e044 81888e00
800365d0 00083544 80468e00 0008da04 817c8e00

Sure enough segment: 0008 offset 80463ea0 DPL 111 = 3

Kd> ln 80463ea0
(80463ea0) NT! Kisystemservice | (80463f75) NT! Kiserviceexit
Exact matches:
NT! Kisystemservice = <no type information>

The IDT position in the system remains the same, at least after I have restarted it. The IDT position exists 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 them as follows, using a slightly different breakdown and terminology from Intel:

Interrupt Gate
An Intel interrupt gate that cannot 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 cannot 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.