lkml.org 
[lkml]   [2010]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv11 2.6.36-rc2-tip 4/15] 4: uprobes: x86 specific functions for user space breakpointing.
(2010/09/06 22:44), Srikar Dronamraju 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.

As you can see in kernel tree, x86 insn decoder has a test
which decodes vmlinux and compares results with objdump.
Similar tests had been done for glibc etc. by Jim.
But crashme looks better. :)

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

Hmm, if you need to validate all instructions, you'd better to
enhance x86 decoder for checking bad instructions.
I think it can be done mostly by adding inat bitflags.

Thank you,

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


\
 
 \ /
  Last update: 2010-09-07 02:59    [W:0.097 / U:2.692 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site