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

[Masami Hiramatsu]

(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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/