On Mon, Apr 14, 2014 at 4:22 PM, Masami Hiramatsu
wrote:
> (2014/04/11 21:23), Denys Vlasenko wrote:
>> On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
>> wrote:
>>> At least, if we can trust Intel SDM, it says that depends
>>> on the operand-size (insn->opnd_bytes) and stack segment
>>>
On Mon, Apr 14, 2014 at 4:22 PM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2014/04/11 21:23), Denys Vlasenko wrote:
On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
At least, if we can trust Intel SDM, it says that depends
on the
(2014/04/11 21:23), Denys Vlasenko wrote:
> On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
> wrote:
>> 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
(2014/04/14 21:24), Denys Vlasenko wrote:
> On Mon, Apr 14, 2014 at 7:14 AM, Masami Hiramatsu
> wrote:
>>> 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
On Mon, Apr 14, 2014 at 7:14 AM, Masami Hiramatsu
wrote:
>> 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[].
What "no"? Is my statement not
On Mon, Apr 14, 2014 at 7:14 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
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[].
What no?
(2014/04/14 21:24), Denys Vlasenko wrote:
On Mon, Apr 14, 2014 at 7:14 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
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
(2014/04/11 21:23), Denys Vlasenko wrote:
On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
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
(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
(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,
On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
wrote:
> 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
On Fri, Apr 11, 2014 at 5:03 AM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
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
(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:
>>
(2014/04/11 2:00), Oleg Nesterov wrote:
> On 04/10, Oleg Nesterov wrote:
>>
>> On 04/10, Masami Hiramatsu wrote:
>>>
>>> (2014/04/10 22:41), Denys Vlasenko wrote:
There is this monstrosity, "16-bit override for branches" in 64-mode:
66 e8 nn nn callw
Nobody sane
(2014/04/10 23:28), Oleg Nesterov wrote:
> On 04/10, 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
On 04/10, Oleg Nesterov wrote:
>
> On 04/10, Masami Hiramatsu wrote:
> >
> > (2014/04/10 22:41), Denys Vlasenko wrote:
> > > There is this monstrosity, "16-bit override for branches" in 64-mode:
> > >
> > > 66 e8 nn nn callw
> > >
> > > Nobody sane uses it because it truncates instruction
On Thursday 10 April 2014 16:30, Denys Vlasenko wrote:
> On 04/10/2014 04:18 PM, Oleg Nesterov wrote:
> > On 04/10, Denys Vlasenko wrote:
> >>
> >> There is this monstrosity, "16-bit override for branches" in 64-mode:
> >>
> >> 66 e8 nn nn callw
> >>
> >> Nobody sane uses it because it
On 04/10/2014 04:18 PM, Oleg Nesterov wrote:
> On 04/10, Denys Vlasenko wrote:
>>
>> There is this monstrosity, "16-bit override for branches" in 64-mode:
>>
>> 66 e8 nn nn callw
>>
>> Nobody sane uses it because it truncates instruction pointer.
>>
>> Or rather, *I think* it should
On 04/10, 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
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
On 04/10, Denys Vlasenko wrote:
>
> There is this monstrosity, "16-bit override for branches" in 64-mode:
>
> 66 e8 nn nn callw
>
> Nobody sane uses it because it truncates instruction pointer.
>
> Or rather, *I think* it should truncate it (i.e. zero-extend to full width),
> but
(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.
>
>
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
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:
(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
On 04/10, Denys Vlasenko wrote:
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.
Or rather, *I think* it should truncate it (i.e. zero-extend to full width),
but conceivably
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
On 04/10, 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
On 04/10/2014 04:18 PM, Oleg Nesterov wrote:
On 04/10, Denys Vlasenko wrote:
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.
Or rather, *I think* it should truncate it
On Thursday 10 April 2014 16:30, Denys Vlasenko wrote:
On 04/10/2014 04:18 PM, Oleg Nesterov wrote:
On 04/10, Denys Vlasenko wrote:
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
On 04/10, Oleg Nesterov wrote:
On 04/10, Masami Hiramatsu wrote:
(2014/04/10 22:41), Denys Vlasenko wrote:
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.
(2014/04/10 23:28), Oleg Nesterov wrote:
On 04/10, 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
(2014/04/11 2:00), Oleg Nesterov wrote:
On 04/10, Oleg Nesterov wrote:
On 04/10, Masami Hiramatsu wrote:
(2014/04/10 22:41), Denys Vlasenko wrote:
There is this monstrosity, 16-bit override for branches in 64-mode:
66 e8 nn nn callw offset16
Nobody sane uses it because it
(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
On Wed, 2014-04-09 at 14:25 -0700, Jim Keniston wrote:
> On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
> > On 04/08, Jim Keniston wrote:
> > >
> > > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > > > 0xe8. Anything else?
>
> Oleg, thanks for responding to (if not
On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
> On 04/08, Jim Keniston wrote:
> >
> > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > > 0xe8. Anything else?
Oleg, thanks for responding to (if not necessarily agreeing with) all my
suggestions. I think your code is solid, but
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.
> The following couple of paragraphs should be included in the code,
> perhaps merged with some of the
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.
The following couple of paragraphs should be included in the code,
perhaps merged with some of the related
On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
On 04/08, Jim Keniston wrote:
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
0xe8. Anything else?
Oleg, thanks for responding to (if not necessarily agreeing with) all my
suggestions. I think your code is solid, but I think
On Wed, 2014-04-09 at 14:25 -0700, Jim Keniston wrote:
On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
On 04/08, Jim Keniston wrote:
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
0xe8. Anything else?
Oleg, thanks for responding to (if not necessarily agreeing
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.
>
The following couple of paragraphs should be included in the code,
perhaps merged with some of the related comments already there. Without
it, the
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.
The following couple of paragraphs should be included in the code,
perhaps merged with some of the related comments already there. Without
it, the code
0xe8. Anything else?
Emulating of rip-relative call is trivial, we only need to additionally
push the ret-address. If this fails, we execute this instruction out of
line and this should trigger the trap, the probed application should die
or the same insn will be restarted if a signal handler
0xe8. Anything else?
Emulating of rip-relative call is trivial, we only need to additionally
push the ret-address. If this fails, we execute this instruction out of
line and this should trigger the trap, the probed application should die
or the same insn will be restarted if a signal handler
44 matches
Mail list logo
