lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 6 Sep 2010 16:16:07 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Jim Keniston <jkenisto@...ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 4/15]  4: uprobes: x86 specific
 functions for user space breakpointing.

On Mon, 6 Sep 2010 19:14:07 +0530
Srikar Dronamraju <srikar@...ux.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@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ