Re: Kernel Mode vs. User Mode

From: Ivan Brugiolo [MSFT] (ivanbrug_at_online.microsoft.com)
Date: 08/13/04 

Date: Fri, 13 Aug 2004 10:45:35 -0700

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

  • Re: Kernel Mode vs. User Mode
    ... thread after every instruction, from which I was pulling the EIP (program ... I'm thinking of other ways to trace the execution of a program. ... threads transition between user mode and kernel mode often. ... > SetThreadContext is a usermode api, so no, it can't be called from kernel ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Problem of calling named NT device in user-mode
    ... my concern replies on device name for user-mode visible. ... I am creating a trivial driver to experience the feature of user-mode ... calling kernel mode driver: ... The name you would want in user mode is ...
    (microsoft.public.development.device.drivers)
  • Re: Problem of calling named NT device in user-mode
    ... I am creating a trivial driver to experience the feature of user-mode ... calling kernel mode driver: ... The name you would want in user mode is ...
    (microsoft.public.development.device.drivers)
  • 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)