Re: Re: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's

[Masami Hiramatsu]

(2014/04/11 2:02), Denys Vlasenko wrote:

>> The (f64) modifier in x86-opcode-map.txt means that inat_is_force64()
>> is true for call opcode. So we won't reach "case 2:" in __get_immv32():
>> insn_get_prefixes() did set insn->opnd_bytes to 2 when it saw 0x66 prefix,
>> but it was before we reach this place, and here we overrode it.
>> This is a bug in insn decoder.
> 
> I tested it on both Intel and AMD CPUs and my worst fears came true:
> this instruction has different widths on different CPUs.
> 
> This program:
> 
> # compile with: gcc -nostartfiles -nostdlib -o int3 int3.S
> _start:         .globl  _start
>                 .byte 0x66,0xe9,0,0
>                 .byte 0,0
> 1: jmp 1b
> 
> compiles to this:
> 
> 00000000004000b0 <_start>:
>   4000b0:       66 e9 00 00             jmpw   b4 <_start-0x3ffffc>
>   4000b4:       00 00                   add    %al,(%rax)
>   4000b6:       eb fe                   jmp    4000b6 <_start+0x6>
> 
> and it will reach 0x4000b6 on Intel CPU.
> IOW, Intel SandyBridge CPU thinks that insn is in fact 66 e9 00 00 00 00,
> no RIP truncation occurs.
> 
> On AMD K10 CPU, the very same binary jumps to 0x00b4
> and gets SIGSEGV with MAPERR.
> AMD thinks that the insn is 66 e9 00 00 as shown above.

Hmm, interesting.

> Thus, insn.c decoder implements Intel's idea of this insn
> while binutils (objdump, gdb) implement AMD decode.

Yeah, insn.c relays on intel's opcode map.

> This same program can be compiled to 32-bit code,
> in this mode both CPUs treat insn as 66 e9 00 00.

In 32 bit mode, insn.c treats it as 66 e9 00 00 correctly.

> Oleg, I'm sure you are very sympathetic by now to the idea
> of just not supporting this insn at all. ;)
> 
> You can check whether insn had any prefix by checking
> insn->prefixes->nbytes != 0...

No, since there are other prefixes (and it may be meaningless)
you should find 0x66 in insn->prefixes->bytes[].

> ..but there is a problem with that. P4 introduced branch hints,
> which are implemented using segment prefixes on conditional jumps.
> Meaning that some compilers produce
> 
> 2e 0f 82 nn nn nn nn
> 
> as   (hint not taken) JB <offset32>   insn.
> 
> 2e is CS segment prefix. insn->prefixes->nbytes == 1 for this insn.
> DS prefix (3e) hints that branch is taken.
> 
> They were nearly useless on P4 anyway and ignored by all CPUs
> before or since, but they can be seen in some programs.

Hm, this could be done.

> 
> Looks like we'll need this:
> 
> /*
>  * 16-bit overrides such as CALLW (66 e8 nn nn) are not supported.
>  * Intel and AMD behavior differ in 64-bit mode: Intel ignores 66 prefix.
>  * No one uses these insns.
>  * To filter them out, reject any branch insns with prefixes...
>  */
> if (insn->prefixes->nbytes > 1)
> 	bail_out;

As I said above, check insn->prefixes.bytes[0..nbytes].

> /*
>  * ...Except a single 3e or 2e "branch taken/not taken" hint prefix.
>  * These are (rarely) used, but ignored by any CPU except P4.
>  * Example: 2e 0f 82 nn nn nn nn  is JB,PN <offset32>
>  */
> if (insn->prefixes->nbytes == 1 && (insn->prefixes->bytes[0] | 0x10) != 0x3e))
> 	bail_out;
> 

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@xxxxxxxxxxx


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