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

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]

Message-ID: <20100906134407.GF14891@linux.vnet.ibm.com>
Date:	Mon, 6 Sep 2010 19:14:07 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Andi Kleen <andi@...stfloor.org>
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.

[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.

> 
> > 
> > validate_insn_32bit is able to identify all valid instructions in a 32
> > bit app and validate_insn_64bits is a superset of
> > validate_insn_32bits; i.e it considers valid 32 bit codes as valid
> > too.
> 
> How can this be? e.g. 32bit has 1 byte INC/DEC but on 64bit
> these are REX prefixes and can be in front of nearly anything.
> So a super set cannot be correct. It has to be either / or.
> 

You are right, the validate_insn_32bits refers to good_insns_32 and
validate_insn_64bits refers to good_insns_64 to decode 1 byte
instructions. Some instructions like 0x06 and 0x0e seem to be valid in
good_insns_32 but not in good_insns_64. 

> > 
> > 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. 
Please correct us if we are wrong, but here is what we do 
- While analyzing the instruction, take into account which register acts
  as the code segment register.

- When interrupted (but before singlestep), copy the contents of the
  register which we think acts as code segment register in our
  above analysis into per-task scratch variable.

- After singlestepping we retrieve the saved per-task scratch
  variable into the corresponding register.

> A heuristic is reasonable (and leave out applications
> that generate 64bit code from 32bit executables or vice versa)
> but you need to test the right personality bits for that.
> 
> 
> > > Also the compat bit is not necessarily set if no system call is
> > > executing. You would rather need to check the exec_domain.
> > 
> > Okay, I shall check and revert on this.
> 
> Hmm actually I double checked and this is a separate bit.
> So scratch that, TIF_32BIT is ok to test.

Okay, Thanks for confirming this.

--
Thanks and Regards
Srikar
--
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/