hxxp://www.summitsoftconsulting.com/NtSystemCalls.htm


abstract:
Most texts that describe Windows NT system calls keep many of the important details in the dark. This leads to confusion when trying to understand exactly what is going on when a user-mode application "calls into" kernel mode. The following article will shed light on the exact mechanism that Windows NT uses when switching to kernel-mode to execute a system service.

nice article, thanks for posting!

well, it isn't very complete imho. i didn't even see the servicedescriptortable being mentioned and such

Shouldn't this be in the advanced forum?

Probably should, done and done.

Hi,

the author of this article somewhat claims that it is not possible to directly call into higher provileged code, therefore an "interrupt gate" would be necessary for this task. But AFAIK, there exist "call gates" in the x86 architecture, which can be located in the GDT and LDT and thus switching to ring 0 by a simple far call is possible. The opposite direction, calling ring 3 from ring 0, is in fact NOT possible, because the cpu needs information about what stack to use and this cannot be defined by a far call (so only a RETF or IRET can "call" out to lower privilegded code).

.

>>But AFAIK, there exist "call gates" in the x86 architecture, which can be located in the GDT and LDT and >>thus switching to ring 0 by a simple far call is possible.

This is not possible in protected mode programming on ia32 because the CPU checks the code segment selector priviledge level CPL, call-gate selector RPL, call gate descriptor DPL, destination code segment descriptor DPL to make sure things like you described won't happen (far call from ring 3 to ring0 unless ring0 code is conforming code). For more details check ia32 manual vol 3 chaptor 4.

Imagine for a second if what you said can be made possible, then the entire ia32 protected mode protection was just made a joke.

If you can install a callgate descriptor in GDT/LDT, you CAN call to ring0.
Proof: ry.pl/~omega/asm/ring0nt.zip

Err, yes, it is. But it's not entirely at intel's door stop, Microsoft is the ones who left the ability for Ring-3 to get at physical memory (and thus modify the descriptor tables). It's amazing what you can get away with...

Call gates are quite cool, but they can bite on occasion if one is not carefull. A few protections I've ran across use them as a "Kiss of Death" to instantly reboot the machine when they detect something's wrong. (invalid instruction in ring 0 reboots machine, while ring 3 just throws exception. Shows up in disasm as same, but depending on HOW the code gets called determines if it simply goes to next level or of you see the BIOS screen...

Call gates are also the basis for most "no-install-needed" root kit stuff, as well as a couple virii.

-sgdt

hmm, it's actually a neat trick by indirection of the callgate descriptor. Scratch everything I said, I just checked the manual again, indeed this satisfies every condition in table 4-1. This is made possible through the installation of a DPL=3 call gate. In addition, an actual stack switch also occurs with this trick so it's real ring 0 switch.

following article

hxxp://www.summitsoftconsulting.com/SysCallOpts.htm

its about how SYSENTER/SYSCALL works in detail (MSR regs and stuff)

cute

too bad it's not much more than a few paragraphs from the manuals. the real interesting stuff is not mentioned at all... think of what happens when you single step SYSENTER... why's SYSENTER_ESP_MSR set to 0? how does the kernel recover?

They could tell you, but then they would have to kill you, so they are doing you a favor by not telling you.

Or, at least that is what they say.

Interesting reading, never the less.

Regards,