Messages in this thread | | | From | Denis Vlasenko <> | Subject | Re: 2.5.63 accesses below %esp (was: Re: ntfs OOPS (2.5.63)) | Date | Mon, 17 Mar 2003 08:56:54 +0200 |
| |
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/
| |