(2014/04/10 23:20), Denys Vlasenko wrote: > On 04/10/2014 03:57 PM, Masami Hiramatsu wrote: >> (2014/04/10 22:41), Denys Vlasenko wrote: >>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote: >>>> On 04/08, Jim Keniston wrote: >>>>> >>>>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote: >>>>>> 0xe8. Anything else? >>>>> >>>>> No, I think e8 is the only call instruction uprobes will see. >>>> >>>> Good. >>> >>> There is this monstrosity, "16-bit override for branches" in 64-mode: >>> >>> 66 e8 nn nn callw <offset16> >>> >>> Nobody sane uses it because it truncates instruction pointer. >> >> No problem, insn.c can handle that too. :) > > That's good that we decode it correctly, > but there is more to it. > > Call insn pushes return address to stack. > > This "mutant 16-bit call", what should it push? > Full RIP? > Truncated 16-bit IP? If yes, by how much does it > advance RSP? +2? +8? > Hmm. Does it affect RSP or only its 16-bit lower part?
At least, if we can trust Intel SDM, it says that depends on the operand-size (insn->opnd_bytes) and stack segment descriptor. Please check the SDM vol.1 6.2.2 Stack Alignment and vol.2a, 3.2 Instructions (A-M), CALL—Call Procedure. But we'd better check it on x86-32. Thank you! > > It's a can of worms! :) -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
