Re: [DynInst_API:] Including arbitrary x86 instructions at snippets

[Buddhika Chamith Kahawitage Don]

Thanks. Will check it out.

On Fri, Mar 16, 2018 at 12:00 PM, Bill Williams  wrote:

> The BPatch interface is not, but the PatchAPI interface is:
>
> http://blog.freearrow.com/software/craft
>
> This distinction is by design: PatchAPI will support an arbitrary code
> generation engine, whereas BPatch is designed to work with
> platform-independent snippets.
>
> --bw
> 
> From: Dyninst-api  on behalf of Buddhika
> Chamith Kahawitage Don 
> Sent: Wednesday, March 14, 2018 11:02 PM
> To: dyninst-api
> Subject: [DynInst_API:] Including arbitrary x86 instructions at snippets
>
> Hi All,
>
> I am considering use Dyninst binary rewriting mode to implement a Control
> Flow Integrity prototype (as mostly described at [1]). For that I need to
> add validation checks around indirect control flow. I wanted to check if
> BPatch API is expressive enough to create snippets with arbitrary x86
> instructions (for example at the validation check I may need to include a
> prefetchnta instruction).
>
> Regards
> Buddhika
>
> [1] https://www.microsoft.com/en-us/research/wp-content/
> uploads/2005/11/ccs05.pdf
>
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] Including arbitrary x86 instructions at snippets

[Bill Williams]

The BPatch interface is not, but the PatchAPI interface is:

http://blog.freearrow.com/software/craft

This distinction is by design: PatchAPI will support an arbitrary code 
generation engine, whereas BPatch is designed to work with platform-independent 
snippets.

--bw

From: Dyninst-api  on behalf of Buddhika 
Chamith Kahawitage Don 
Sent: Wednesday, March 14, 2018 11:02 PM
To: dyninst-api
Subject: [DynInst_API:] Including arbitrary x86 instructions at snippets

Hi All,

I am considering use Dyninst binary rewriting mode to implement a Control Flow 
Integrity prototype (as mostly described at [1]). For that I need to add 
validation checks around indirect control flow. I wanted to check if BPatch API 
is expressive enough to create snippets with arbitrary x86 instructions (for 
example at the validation check I may need to include a prefetchnta 
instruction).

Regards
Buddhika

[1] 
https://www.microsoft.com/en-us/research/wp-content/uploads/2005/11/ccs05.pdf

___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] Telling DynInst a particular function is non-returning

[Thomas Dullien]

Hey there,

update: It seems that the obj.cs()->linkage() at the beginning of
Parser::Parser returns an empty
plt ?

Cheers,
Thomas

On Fri, Mar 16, 2018 at 4:39 PM, Thomas Dullien 
wrote:

> Hey there,
>
> ok, tracing this a bit further, I have some more questions :-)
>
> If I am not mistaken, the code around Parser.C, line 1013 is supposed to
> deal with calls to non-returning targets?
>
> is_nonret = obj().cs()->nonReturning(target);
> if (is_nonret) {
>  
>
> Now, in my example, for some reason the .plt.got stub function that jmps
> straight to cs:__stack_chk_fail is not a
> function:
>
> .plt.got:1030 __stack_chk_fail proc near  ; CODE
> XREF: postproc_version:loc_11D0↓p
> .plt.got:1030 ;
> postproc_configuration:loc_1202↓p ...
> .plt.got:1030 jmp cs:__stack_chk_fail_ptr
> .plt.got:1030 __stack_chk_fail endp
>
> So when nonReturning(0x1030) is called, no function gets returned in
> SymtabCodeSource::nonReturning while
> calling findFuncByEntryOffset, and then the code mistakenly adds the
> fallthrough edge.
>
> I am still finding my way through the codebase - but I presume there is
> some initial pass that is supposed to create
> functions from the stubs in the PLT and check them for non-returning
> status?
>
> Cheers,
> Thomas
>
>
>
> On Thu, Mar 15, 2018 at 6:33 PM, Thomas Dullien 
> wrote:
>
>> Hey there,
>>
>> one quick question: After backporting the 3 commits, I tested with both
>> recursive-mode disassembly and non-recursive mode
>> disassembly, and neither of the two worked. My question is now: Is this
>> even supposed to work in non-recursive mode? E.g.
>> if we are not recursing into a called function, we can't tell whether it
>> returns or not, right?
>>
>> Cheers,
>> Thomas
>>
>> On Thu, Mar 15, 2018 at 2:23 PM, Thomas Dullien > > wrote:
>>
>>> Hey there,
>>>
>>> ah, cool :-). I backported the 3 commits into the 9.3.2 codebase, but it
>>> does not seem to solve the issue just yet.
>>>
>>> I will debug a bit more and report back once I understand what is going
>>> on.
>>>
>>> Cheers,
>>> Thomas
>>>
>>> On Thu, Mar 15, 2018 at 2:09 PM, Xiaozhu Meng  wrote:
>>>
 Ah, I have a few pending commits related to this issue. Please look at
 my pull request at https://github.com/dyninst/dyninst/pull/437.

 Not all commits are relevant to you, but bbac557, 78b1bd1, da50a37 should
 be relevant.

 For parsing_printf, it is "DYNINST_DEBUG_PARSING".


 On Thu, Mar 15, 2018 at 8:02 AM, Thomas Dullien <
 thomasdull...@google.com> wrote:

> Hey there,
>
> ok, rebuilding DynInst 9.3.2 now to investigate why adding the string
> does not seem to have any effect.
> I looked at the source code, and I *think* the function is already in
> the list of non-returning functions.
>
> Checking what is going on. Example setup:
>
> .plt.got:00053CF8 __stack_chk_fail proc near  ;
> CODE XREF: init:loc_54673↓p
> .plt.got:00053CF8 ;
> uninit:loc_54705↓p ...
> .plt.got:00053CF8 jmp
>  cs:__stack_chk_fail_ptr
> .plt.got:00053CF8 __stack_chk_fail endp
>
> .text:000A4290 var_8   = qword ptr -8
> .text:000A4290
> .text:000A4290 graph = rdi ;
> AVFilterGraph_0 *
> .text:000A4290 flags = rsi ;
> unsigned int
> .text:000A4290 ; __unwind {
> .text:000A4290 pushrax
> .text:000A4291 mov rax, fs:28h
> .text:000A429A mov [rsp+8+var_8], rax
> .text:000A429E mov [graph+5Ch], esi
> .text:000A42A1 mov rax, fs:28h
> .text:000A42AA cmp rax, [rsp+8+var_8]
> .text:000A42AE jnz short loc_A42B2
> .text:000A42B0 pop rax
> .text:000A42B1 retn
> .text:000A42B2 ; --
> -
> .text:000A42B2
> .text:000A42B2 loc_A42B2:  ; CODE
> XREF: avfilter_graph_set_auto_convert+1E↑j
> .text:000A42B2 call__stack_chk_fail
> .text:000A42B2 ; } // starts at A4290
> .text:000A42B2 avfilter_graph_set_auto_convert endp
>
> DynInst for some reason does not interpret the tailing call as
> non-return. Digging to see what is going on,
> will update here as I learn more :)
>
> Cheers,
> Thomas
>
>
> On Thu, 

Re: [DynInst_API:] Telling DynInst a particular function is non-returning

[Thomas Dullien]

Hey there,

ok, tracing this a bit further, I have some more questions :-)

If I am not mistaken, the code around Parser.C, line 1013 is supposed to
deal with calls to non-returning targets?

is_nonret = obj().cs()->nonReturning(target);
if (is_nonret) {
 

Now, in my example, for some reason the .plt.got stub function that jmps
straight to cs:__stack_chk_fail is not a
function:

.plt.got:1030 __stack_chk_fail proc near  ; CODE
XREF: postproc_version:loc_11D0↓p
.plt.got:1030 ;
postproc_configuration:loc_1202↓p ...
.plt.got:1030 jmp cs:__stack_chk_fail_ptr
.plt.got:1030 __stack_chk_fail endp

So when nonReturning(0x1030) is called, no function gets returned in
SymtabCodeSource::nonReturning while
calling findFuncByEntryOffset, and then the code mistakenly adds the
fallthrough edge.

I am still finding my way through the codebase - but I presume there is
some initial pass that is supposed to create
functions from the stubs in the PLT and check them for non-returning status?

Cheers,
Thomas



On Thu, Mar 15, 2018 at 6:33 PM, Thomas Dullien 
wrote:

> Hey there,
>
> one quick question: After backporting the 3 commits, I tested with both
> recursive-mode disassembly and non-recursive mode
> disassembly, and neither of the two worked. My question is now: Is this
> even supposed to work in non-recursive mode? E.g.
> if we are not recursing into a called function, we can't tell whether it
> returns or not, right?
>
> Cheers,
> Thomas
>
> On Thu, Mar 15, 2018 at 2:23 PM, Thomas Dullien 
> wrote:
>
>> Hey there,
>>
>> ah, cool :-). I backported the 3 commits into the 9.3.2 codebase, but it
>> does not seem to solve the issue just yet.
>>
>> I will debug a bit more and report back once I understand what is going
>> on.
>>
>> Cheers,
>> Thomas
>>
>> On Thu, Mar 15, 2018 at 2:09 PM, Xiaozhu Meng  wrote:
>>
>>> Ah, I have a few pending commits related to this issue. Please look at
>>> my pull request at https://github.com/dyninst/dyninst/pull/437.
>>>
>>> Not all commits are relevant to you, but bbac557, 78b1bd1, da50a37 should
>>> be relevant.
>>>
>>> For parsing_printf, it is "DYNINST_DEBUG_PARSING".
>>>
>>>
>>> On Thu, Mar 15, 2018 at 8:02 AM, Thomas Dullien <
>>> thomasdull...@google.com> wrote:
>>>
 Hey there,

 ok, rebuilding DynInst 9.3.2 now to investigate why adding the string
 does not seem to have any effect.
 I looked at the source code, and I *think* the function is already in
 the list of non-returning functions.

 Checking what is going on. Example setup:

 .plt.got:00053CF8 __stack_chk_fail proc near  ;
 CODE XREF: init:loc_54673↓p
 .plt.got:00053CF8 ;
 uninit:loc_54705↓p ...
 .plt.got:00053CF8 jmp
  cs:__stack_chk_fail_ptr
 .plt.got:00053CF8 __stack_chk_fail endp

 .text:000A4290 var_8   = qword ptr -8
 .text:000A4290
 .text:000A4290 graph = rdi ;
 AVFilterGraph_0 *
 .text:000A4290 flags = rsi ;
 unsigned int
 .text:000A4290 ; __unwind {
 .text:000A4290 pushrax
 .text:000A4291 mov rax, fs:28h
 .text:000A429A mov [rsp+8+var_8], rax
 .text:000A429E mov [graph+5Ch], esi
 .text:000A42A1 mov rax, fs:28h
 .text:000A42AA cmp rax, [rsp+8+var_8]
 .text:000A42AE jnz short loc_A42B2
 .text:000A42B0 pop rax
 .text:000A42B1 retn
 .text:000A42B2 ; --
 -
 .text:000A42B2
 .text:000A42B2 loc_A42B2:  ; CODE
 XREF: avfilter_graph_set_auto_convert+1E↑j
 .text:000A42B2 call__stack_chk_fail
 .text:000A42B2 ; } // starts at A4290
 .text:000A42B2 avfilter_graph_set_auto_convert endp

 DynInst for some reason does not interpret the tailing call as
 non-return. Digging to see what is going on,
 will update here as I learn more :)

 Cheers,
 Thomas


 On Thu, Mar 15, 2018 at 1:58 PM, Xiaozhu Meng  wrote:

> Hi Thomas,
>
> On Thu, Mar 15, 2018 at 4:06 AM, Thomas Dullien <
> thomasdull...@google.com> wrote:
>
>> Hey there,
>>
>> ok, I have looked at a few options on how to best tackle this, and
>> would love to solicit advice :-)
>>
>> - I tried