Re: 2.5.63 accesses below %esp (was: Re: ntfs OOPS (2.5.63))
Denis Vlasenko (email@example.com)
Mon, 17 Mar 2003 08:56:54 +0200
On 15 March 2003 20:34, Horst von Brand wrote:
> Denis Vlasenko <firstname.lastname@example.org> said:
> > On 13 March 2003 23:04, Horst von Brand wrote:
> > > Szakacsits Szabolcs <email@example.com> 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...).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/