Re: Kernel Mode vs. User Mode

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Ben Rush (kwendex_at_yahoo.com)
Date: 08/13/04 

Date: Fri, 13 Aug 2004 10:37:42 -0500

Thanks all for the responses. I hope my response isn't too wordy, so please
bare with me.....

I got a lot of my questions answered by you guys and by re-discovering the
Intel manuals online. Basically my interests are totally academic as I'm not
sure I could accomplish much else in this area right now with my
knowledge-level being so low. I'm clearly in the exploration and discovery
phase; so I appreciate all of the patience you have shown.

My "goal", I guess I might call it, was to have an application that
essentially set the TF bit and therefore set the processor into single step
mode. I would catch the exception in a debugger I've written and then reset
the bit, etc. Essentially this would enable me to get the CONTEXT for the
thread after every instruction, from which I was pulling the EIP (program
counter) and saving it into memory. The ultimate end was to trace the
program counter through the thread's execution and then print out a
dissasembly of the instructions executed (I'm currently building the
dissassembler). Anyway....the result turned out to be a ton of data; and so
I'm thinking of other ways to trace the execution of a program. One idea I
had was to look for each CALL instruction and replace it with an INT 3 and
the record each exception, etc (doing all of the appropriate back-patching
so that it would still be executed, etc.)

I have the EIP tracer utility done for the most part. I guess one of my main
questions was, which I think I have answered, to verify that I am getting
only user-mode instructions in the list of EIPs that I have dumped. But
since SetThreadContext() is what I'm using to change the TF bit and this
function is user-mode and therefore couldn't modify a thread executing under
kernel mode (I'm assuming this is correct), I know all of the EIPs I am
getting are for code that is executing in user space.

So, my question now is how can I get ahold of the GDT and index into it to
find various memory segments described by it. Say I wanted to be sure that a
region of memory I'm looking at isn't within the kernel-mode address space
as described by the GDT, or I wanted to write a utility which printed the
contents of the GDT to the screen, etc. (again, this is purely academic so
it may not be *practical*, but it is *interesting*). I know assembly and so
can do inline assembly code, but I would rather try to do it with the Win32
API. I see the instruction LGDT - is this what I would use? Or is there a
better way?

Thanks for the interesting talk,
Ben

"Steve Dispensa [MVP]" <dispensa@positivenetworks.net> wrote in message
news:eIT3ApOgEHA.3948@TK2MSFTNGP11.phx.gbl...
> Ben Rush wrote:
>> Assumption 1: A thread either executes in kernel mode or user mode.
>
> Sort of; threads transition between user mode and kernel mode often. Every
> time a user program calls a system call, the tread transitions. The
> distinction between user mode and kernel mode is really just CPL.
> Everything follows from that. Well, and you get a kernel stack when you
> get into kernel mode, and you have to go through a trap gate to get there.
>
> One interesting point is this - your thread can be running along in
> usermode and can be commondered for use in kernel mode by an interrupt
> handler, can be further used by various DPC functions, etc., before
> resuming work in your user-mode code, without you ever having known about
> it.
>
>> Assumption 2: A thread, once it has executed kernel mode code, is always
>> in kernel mode.
>
> Nope, see above.
>
>> Assumption 3: A thread can exist in both kernel mode or user mode at
>> different times during its execution.
>
> Yep.
>
>> Assumption 4: ::SetThreadContext() cannot be executed on a thread that is
>> executing in kernel-mode.
>
> SetThreadContext is a usermode api, so no, it can't be called from kernel
> mode code. Depending on how your code got into kernel mode, you can
> indeed schedule an APC on your thread to call whatever function you like
> while your thread is in kernel mode, assuming it's not already at
> APC_LEVEL or above, and that you're not in a critical region.
>
> There are kernel APIs that manipulate threads, too - see for example
> NtSetContextThread and PsSetContextThread. These APIs only modify
> usermode context. If the kernel wants to do something in a specific
> thread context, it usually queues an APC to that thread. In fact, the
> above-mentioned routines just queue a normal kernel APC to the target
> thread when a user calls SetThreadContext. [Thanks to Ken Johnson of
> Positive Networks for reviewing this explanation.]
>
>> I'm trying to find some definitive resources on threads and how they
>> switch between "modes", or whether they do at all. So far I'm just
>> piecing bits together that I find scattered throughout the Internet. Any
>> pointers would be helpful.
>
> If you have specific questions, feel free to post them here.
>
> -sd
>
> ----------------------
> Steve Dispensa
> Windows DDK MVP
> Positive Networks

Relevant Pages

  • Re: Kernel Mode vs. User Mode
    ... Couldn't you replace the instruction after the transition with a breakpoint? ... >the boundary between kernel and user space) then at that point I'm practically at a loss as ... >>> I'm thinking of other ways to trace the execution of a program. ... threads transition between user mode and kernel mode often. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Kernel Mode vs. User Mode
    ... The overall goal of your task is doable till you are in user-mode, but, ... > I'm thinking of other ways to trace the execution of a program. ... A thread either executes in kernel mode or user mode. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Kernel Mode vs. User Mode
    ... "Ben Rush" wrote in message ... A thread either executes in kernel mode or user mode. ... then the execution is resummed to the application. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: program execution in user space and in kernel space.
    ... program execution in kernel space. ... But what about in user space? ... The important difference is between the CPU's kernel mode and user ...
    (comp.os.linux.development.system)
  • Signal catch code; can it make kernel commands
    ... When a signal is sent to the computer the CPU switches to kernel mode. ... the execution of this code so kernel commands that are placed in the ...
    (comp.unix.programmer)