Original from  Jonathan de Boyne Pollard  to Denis Tonn on 10-06-1998
Original Subject: How do DLLs load and unlo

                         ---------------------------------------

  JP>> And how does the call gate that is the "return" from the 
  JP>> InitTerm function protect itself from malicious code that 
  JP>> would otherwise use it as a back door for entering the 
  JP>> kernel at any place that it liked ?
 
  DT> That callgate never returns from the kernel code. It enters the 
  DT> kernel at a *particular* place. All callgates have SPECIFIC addresses
  DT> that they point to, it is part of the Intel specs. [...]
 
JP> What I was getting at was based on the idea that there was 
JP> one, generic, callgate that was used for all "returns" from 
JP> ring 3 code.  This would imply that the ring 3 code would 
JP> need to supply the address of the kernel code to "return" 
JP> to as a parameter to the callgate function.  This is, of 
JP> course, a security hole.
JP> 
JP> If I understand you correctly, however, this is not the case.  Instead, there 
JP> is one call gate for *each individual type* of "return" 

 No.. There is a DIFFERENT ring 0 stack for each thread (in the TSD). 
The hardware automaticly switches to the Ring 0 stack as part of the
callgate redirection (virtual address in the TSS). Part of thread
context switching is to page map the TSD into this virtual address in 
the TSS. 
 Once though the callgate and back in Ring 0 (with that thread's Ring 
0 stack), a simple RET in the Ring 0 code is all that is needed to
return to the appropriate code that did the callback. 

JP> (i.e. one for returns from InitTerm functions, another for 
JP> returns from exception handlers, and so forth), meaning 
JP> that there's no need for the ring 3 code to supply the 
JP> return address, since each callgate "knows" what part of 
JP> the kernel caused it to be invoked from a callback, and so 
JP> "knows" what part of the kernel to "return" to; and so 
JP> there is no security hole whereby ring 3 code can arrange 
JP> to "return" to arbitrary points in the kernel.

 It's even simpler than that. You haven't fully thought out the 
implications of a separate Ring 0 stack for EACH thread. This is NOT 
the kernel mode stack, it is for "application context Ring 0 code" 
only.
 All threads calling an API initially enter the kernel with their own 
unique R0 stack, and any traps while this stack is active are
"reflected" back at the app/process (and the system keeps running).
The kernel changes to it's own internal stack (and also becomes
non-preemptable) when it enters Kmode. 
 This same stack, being unique per thread, is used for the R3 callback 
"return thru a callgate" on the R0 side of the wall. 



   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
 

 





--- Maximus/2 3.01