Re: [PATCHv11 2.6.36-rc2-tip 4/15] 4: uprobes: x86 specific functions for user space breakpointing.

[Andi Kleen <andi@firstfloor.org>]

On Mon, 6 Sep 2010 19:14:07 +0530
Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:

> [adding Masami and Jim to the copy list] 
> 
> > > I havent tried any fuzz tests with the instruction decoder. But I
> > > am not sure if Masami has tried that out some of these. 
> > > One question: Do you want to test uprobes with crashme or test
> > > instruction decoder with crashme.
> > 
> > Ideally both, but as a minimum the part that is exposed
> > to user space, that is uprobes.
> 
> Okay, I will test uprobes with crashme.

crashme and valid 1/2 bit corrupted code please if possible. I'm 
not sure crashme alone has enough coverage.


> > > 
> > > Did you get a chance to look at
> > > validate_insn_32bit/validate_insn_64bits? If you feel that
> > > validate_insn_32bit/validate_insn_64bits? are unable to detect
> > > valid codes, then I will certainly rework.
> > 
> > I don't think you can do a 100% solution because for 100%
> > you would need to know the code segment the CPU is going
> > to use later, and that's not possible in advance.
> > 
> 
> I think you are referring to RIP related instructions, this how we
> handle them. 

I just meant regarding long mode vs compat mode which defines
whether REX prefixes are valid or not. Because this can
change any time (if the application does a long jump) you
cannot know in advance what it is going to use. But 
it's also very rare to use long jumps at all, so this
can be probably ignored (but should be documented somewhere),
and just guess based on the executable. I just wanted
to point out that it's not a 100% solution.

I don't think you need to care about segment bases either. While
they can be used (16bit Wine or dosemu) it's quite rare
and not supporting uprobes for this is totally reasonable.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.