mirror of
https://github.com/reactos/reactos.git
synced 2024-12-29 10:35:28 +00:00
9393fc320e
Excluded: 3rd-party code (incl. wine) and most of the win32ss.
142 lines
5.8 KiB
Text
142 lines
5.8 KiB
Text
|
|
Correction / addition to Prasad's "Undocumented NT"
|
|
|
|
From: dan_ps@my-deja.com
|
|
Reply to: dan_ps@my-deja.com
|
|
Date: Sun, 23 Apr 2000 10:03:30 GMT
|
|
Organization: Deja.com - Before you buy.
|
|
Newsgroups:
|
|
comp.os.ms-windows.programmer.nt.kernel-mode
|
|
Followup to: newsgroup
|
|
|
|
|
|
Recently , I had a chanche to borrow "Undocumented NT" by Mr Prasad
|
|
Dabak from one of my friends and read it. While reading the chapters
|
|
regarding builidng your own interrupt handlers or callgates under NT ,
|
|
I found that the book glosses over very important topics such as IDT
|
|
in SMP enviroments , and a complete wrong presentation of what structure
|
|
a interrupt handler is supposed to build on the stack to ensure shamless
|
|
OS functionality. Mr's Prasad choice is a straigtforward pushad ,
|
|
folowed by setting the FS segment to the ring0 PCR selector. This way
|
|
to build a trap frame for a interrupt is still used in Windows 95 ,
|
|
but in Windows NT , the layout of a correct Trap Frame is a little bit
|
|
more complex.
|
|
The correct layout for a Trap Frame is the folowing: (note that
|
|
it consitis from two parts , a stack frame wich is built by the CPU
|
|
according to mode in wich was the CPU when the exception or software
|
|
interrupt was generated , and a Context Capure frame who has to be built
|
|
by the exception handler itself )
|
|
|
|
struc KeTrapFrame
|
|
|
|
.DebugEBP resd 1 ; 00
|
|
.DebugEIP resd 1 ; 04
|
|
.DebugArgMark resd 1 ; 08
|
|
.DebugPointer resd 1 ; 0C
|
|
.TempCS resd 1 ; 10
|
|
.TempEsp resd 1 ; 14
|
|
|
|
.DR0 resd 1 ; 18
|
|
.DR1 resd 1 ; 1C
|
|
.DR2 resd 1 ; 20
|
|
.DR3 resd 1 ; 24
|
|
.DR6 resd 1 ; 28
|
|
.DR7 resd 1 ; 2C
|
|
.GS resw 1 ; 30
|
|
resw 1 ; 32
|
|
.ES resw 1 ; 34
|
|
resw 1 ; 36
|
|
.DS resw 1 ; 38
|
|
resw 1 ; 3A
|
|
.EDX resd 1 ; 3C
|
|
.ECX resd 1 ; 40
|
|
.EAX resd 1 ; 44
|
|
.PreviousMode resd 1 ; 48
|
|
.ExceptionList resd 1 ; 4C
|
|
.FS resw 1 ; 50
|
|
resw 1 ; 52
|
|
.EDI resd 1 ; 54
|
|
.ESI resd 1 ; 58
|
|
.EBX resd 1 ; 5C
|
|
.EBP resd 1 ; 60
|
|
.Error resd 1 ; 64
|
|
.EIP resd 1 ; 68
|
|
.CS resw 1 ; 6C
|
|
resw 1 ; 6E
|
|
.EFLAGS resd 1 ; 70
|
|
.ESP resd 1 ; 74
|
|
.SS resw 1 ; 78
|
|
resw 1 ; 7A
|
|
.ES_V86 resw 1 ; 7C
|
|
resw 1 ; 7E
|
|
.DS_V86 resw 1 ; 80
|
|
resw 1 ; 82
|
|
.FS_V86 resw 1 ; 84
|
|
resw 1 ; 86
|
|
.GS_V86 resw 1 ; 88
|
|
endstruc
|
|
|
|
Note that this is the complete layout of a TrapFrame structure.
|
|
Depending in what mode the CPU was when the exception occured , it may
|
|
break earlier than .GS_V86. Also , it seems that fields above .DR0 are
|
|
required only to debug builds. The declaration is for NASM , a free X86
|
|
assembler , but this shouldnt have any kind of importance.
|
|
|
|
Now why one should build the correct layout for this stack
|
|
frame ? The answer is that for shamlees operation of OS , a interrupt
|
|
handler HAS to poke into interrupted thread's KTHREAD strucure a
|
|
pointer to current TrapFrame existing on stack. This pointer will be
|
|
later used by several ntoskrnl API's to gain access to interrupted
|
|
thread;s acccess registers , or to gain information about the
|
|
interrupted thread's ring3 stack location , or simply to capture all
|
|
this information and package it into the form of a CONTEXT structure.
|
|
Since ntoskrnl assumes the above layout for a stack frame , using any
|
|
other structure size or layout can lead to unforeseen consequences.
|
|
|
|
Other things wich one may want to do when building a stack
|
|
frame are : (assumes that the handler already set the FS register to
|
|
kernel PCR selector )
|
|
|
|
1. Save old Exception List head , and patch -1 to FS:0 ( thus
|
|
overriding any potentialy pre-existing SEH handlers.
|
|
|
|
2. Determine whatever the interrupted thread was runing in
|
|
ring0 or in ring3 and save this information in PreviousMode field of
|
|
The Trap frame. This is also important , since many internal API's will
|
|
check the Provious mode , acting differently in each case. (check CS
|
|
image on stack for this )
|
|
|
|
3. Get a pointer to the top of KeTrapFrame , and patch it into
|
|
KTHREAD structure, at KTHREAD->TrapFrame. if ya want the layout of
|
|
TrapFrame , there are multiple places where one can get it , but Im
|
|
willing to post it here on request.
|
|
|
|
4. In the case that the hardware stack built by CPU does not
|
|
contain an error code , fake one ( generaly , aborts always push an
|
|
error code on stack , some exceptions do , and traps never push an
|
|
error code by deafult. Suplimentary information can be found in intel
|
|
arch. reference manual .
|
|
|
|
5. Optionaly enable the interrupts trough a STI . NT uses
|
|
usualy interrupt gates , so the CPU will clear IF upon entering an
|
|
exception handler. Note that in the case handling the interrupt or
|
|
exception trough a trap gate , IF will not be automaticly cleared.
|
|
|
|
If you are interesting in the code wich can actualy build such
|
|
a structure on the stack , use a kernel debugger and Break on Int
|
|
0x2E , and single step the code .
|
|
|
|
As last words , I want to ensure Mr Prasad of my respect , and
|
|
the thing that the only reason for this posting is my feeling that all
|
|
holes must be covered , for the sake of all NT driver writing comunity.
|
|
|
|
Later , Dan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sent via Deja.com http://www.deja.com/
|
|
Before you buy.
|