Re: Kernel Mode vs. User Mode

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

Date: Fri, 13 Aug 2004 14:39:32 -0500

I think my task is really moot, then, if it involves any real-world
applications. Please let me know if I'm wrong, but if I can't trace through
the "trap-code" (which I presume is the boundary between kernel and user
space) then at that point I'm practically at a loss as to when to start
tracing again because the thread has essentially "gone-silent" while its in
kernel space. I wouldn't know when to start tracing again; because when it
comes out of kernel space would be unknown to me.

I read the other night about the 'wt' functionality and have used it
lightly - but like I said I'm more interested in learning how to do it
myself than anything else at this point.

I think I'll try inserting INT 3 instructions at each CALL instruction, and
then after it gets caught I'll record that it got caught, back-patch the
CALL instruction, unwind the EIP and continue, etc. I think I could probably
trace well doing that. Besides, that will teach me more about modifying
executable code in-memory, etc.

"Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in message
news:%23euRZ1VgEHA.2468@TK2MSFTNGP12.phx.gbl...
> Please look at the 'wt' functionality in the cdb/ntsd/windbg debuggers.
> The overall goal of your task is doable till you are in user-mode, but,
> if you need to track U-2-K and K-2-U transitions, and still do tracing,
> then you should consider a different approach.
> Even the Kernel Debugging support in NT-derivative OSes does
> not allow you to trace through the trap-code.
> This can be done with debuggers that supports ICEs and physical debug
> ports
> of modern CPUs.
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Ben Rush" <kwendex@yahoo.com> wrote in message
> news:uOyQ6tUgEHA.712@TK2MSFTNGP09.phx.gbl...
>> 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