Re: Kernel Mode vs. User Mode
From: Tom Stewart (tastewar_at_newsgroups.nospam)
Date: 08/17/04
- Next message: Tom Stewart: "Re: Process Idle Time"
- Previous message: Tom Stewart: "Re: IMAPI IDiscMaster::SetActiveDiscRecorder() Problem"
- In reply to: Ben Rush: "Re: Kernel Mode vs. User Mode"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 17 Aug 2004 09:09:47 -0400
Couldn't you replace the instruction after the transition with a breakpoint?
-- Tom "Ben Rush" <kwendex@yahoo.com> wrote in message news:uw8yC1WgEHA.2812@tk2msftngp13.phx.gbl... >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 >>> >>> >> >> > >
- Next message: Tom Stewart: "Re: Process Idle Time"
- Previous message: Tom Stewart: "Re: IMAPI IDiscMaster::SetActiveDiscRecorder() Problem"
- In reply to: Ben Rush: "Re: Kernel Mode vs. User Mode"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
