[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5346A8BE.5060401@redhat.com>
Date: Thu, 10 Apr 2014 16:20:46 +0200
From: Denys Vlasenko <dvlasenk@...hat.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC: Oleg Nesterov <oleg@...hat.com>,
Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Anton Arapov <aarapov@...hat.com>,
David Long <dave.long@...aro.org>,
"Frank Ch. Eigler" <fche@...hat.com>,
Jonathan Lebon <jlebon@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's
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?
It's a can of worms! :)
--
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/
Powered by blists - more mailing lists