Re: 2.5.63 accesses below %esp (was: Re: ntfs OOPS (2.5.63))

[Jonathan Lundell <jlundell@lundell-bros.com>]

At 8:29pm -0800 3/13/03, Randy.Dunlap wrote:
>  > If you've got a symbol some reasonable distance before EIP, you could
>>  decode from there. I wrote a little code that does that (using
>>  kallsyms) very crudely in the stack trace in order to give the reader  a
>>  hint about stack frames. Go to the prior symbol, which is usually  an entry
>>  point, and find the %esp arithmetic. Works pretty well for  figuring out the
>>  real call chain.
>
>as long as it's not a data symbol...
>can you determine that?

Sometimes/mostly, and btw my code is i386-only. The trace is question 
is arch/i386/kernel/traps.c:show_trace(). It already makes the test 
kernel_text_address(), which works in the kernel, but not for modules 
(at least in the kernel I'm using: 2.4.9 (don't ask)).

For addresses in the trace (as opposed to the trapped EIP), I look 
for a call instruction preceding the putative return address. That's 
backwards assembly, but since there are relatively few possibilities, 
it seems to work fairly well.

So finding a call is a good clue that we're looking at text. Look 
back from the call for argument pushes (I stop at the first non-push, 
because of the backwards-disassembly problem), then go to the 
previous symbol and scan forward for pushes and subtracts from %esp. 
The sum of all those, plus four bytes for the return link, gives me a 
lower limit on frame size. It's not perfect; a real disassembly 
forward from the symbol would maybe be better, but that seems like 
overkill (what to do with branches, etc).

The idea isn't to be perfect anyway, but to give me hints for 
manually reconstructing the call chain. Way better than nothing.

But for your purposes, disassembling from the previous symbol gives 
you a code dump, and you know that EIP had better be pointing to text.
-- 
/Jonathan Lundell.