lkml.org 
[lkml]   [2003]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.5.63 accesses below %esp (was: Re: ntfs OOPS (2.5.63))
Date
On 15 March 2003 20:34, Horst von Brand wrote:
> Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> said:
> > On 13 March 2003 23:04, Horst von Brand wrote:
> > > Szakacsits Szabolcs <szaka@sienet.hu> said:
> > > > On Wed, 12 Mar 2003, Horst von Brand wrote:
> > > > > It is _hard_ to do with variable length instructions (CISC,
> > > > > remember?), the code is designed to be easily decoded
> > > > > forward, noone executes code going backwards.
> > > >
> > > > Of course, it's a bad approach. You start earlier and stop at
> > > > EIP. Repeat this for max(instruction length) different offsets
> > > > and you will have the winner. Figure it out from the context
> > > > after EIP.
> > >
> > > By hand, OK. Automatically, no.
> >
> > Why not? Disassemble from, say, EIP-16 and check whether you
> > have an instruction starting exactly at EIP. If no, repeat from
> > EIP-15, -14... You are guaranteed to succeed at EIP-0 ;)
>
> But your previous success (if any) doesn't mean anything, and might
> even screw up the decoding after EIP

How come? If I started to decode at EIP-n and got a sequence of
instructions at EIP-n, EIP-n+k1, EIP-n+k2, EIP-n+k3..., EIP,
instructions prior to EIP can be wrong. Instruction at EIP
and all subsequent ones ought to be right.

> (if accidentally an address
> looks like an instruction, say). This is too much work (to get right)
> for something of purely informational value (if that much), generated
> by a suspect kernel (an Oops is when something went wrong...).
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.106 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site