Re: [go-nuts] Re: [RFC] Dynamically instrumentation Go binaries

[Julio Guerra]

On Fri, Nov 16, 2018 at 12:06 AM Damian Gryski  wrote:

> One approach would be to augment the compiler to instrument the binary
> with the techniques outlined in:
>
> XRay: A Function Call Tracing System
> https://ai.google/research/pubs/pub45287
>
>
Yes, this is very likely the best option for performance and to avoid code
relocation at run time... Unfortunately, the go toolchain currently doesn't
have any "plugin" interface to add extra compilation stages.

-- 
Julio Guerra

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [RFC] Dynamically instrumentation Go binaries

['Kevin Malachowski' via golang-nuts]

If you can't recompile the binary, an option is to use a generic dynamic 
instrumentation platform like DynamoRIO 
 (which I think works for Go 
programs after a recent bugfix). It works on windows, mac, and linux, and 
has been used in the past for various security-based testing and 
verification. Plenty of papers available on the 
website: http://dynamorio.org/pubs.html



On Thursday, November 15, 2018 at 3:06:11 PM UTC-8, Damian Gryski wrote:
>
> One approach would be to augment the compiler to instrument the binary 
> with the techniques outlined in:
>
> XRay: A Function Call Tracing System
> https://ai.google/research/pubs/pub45287
>
> Damian
>
> On Thursday, November 15, 2018 at 9:09:19 AM UTC-8, ju...@sqreen.io wrote:
>>
>> Hi,
>>
>> I am working on dynamic instrumentation of Go programs at run time, 
>> possibly without static source-code instrumentation. As I would like a 
>> solution as close to Go and standard as possible, I was first thinking of 
>> using `go generate` to generate a file adding things `reflect` doesn't 
>> provide such as the list of packages, functions, global variables... That 
>> way, I should be able to use `reflect` to modify any dynamic calls by 
>> modifying the method tables of their underlying type representations.
>>
>> But regarding statically linked calls, the less intrusive technique I 
>> found are uprobes, which is linux-specific. And at the opposite, there are 
>> user-space binary code instrumentation libraries such as dyninst that 
>> modify the code at run time...
>>
>> So I am wondering if anyone here has any thoughts on this subject, that 
>> doesn't seem to be solved for Go programs.
>>
>> Thanks!
>>
>> Julio
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [RFC] Dynamically instrumentation Go binaries

[Damian Gryski]

One approach would be to augment the compiler to instrument the binary with 
the techniques outlined in:

XRay: A Function Call Tracing System
https://ai.google/research/pubs/pub45287

Damian

On Thursday, November 15, 2018 at 9:09:19 AM UTC-8, ju...@sqreen.io wrote:
>
> Hi,
>
> I am working on dynamic instrumentation of Go programs at run time, 
> possibly without static source-code instrumentation. As I would like a 
> solution as close to Go and standard as possible, I was first thinking of 
> using `go generate` to generate a file adding things `reflect` doesn't 
> provide such as the list of packages, functions, global variables... That 
> way, I should be able to use `reflect` to modify any dynamic calls by 
> modifying the method tables of their underlying type representations.
>
> But regarding statically linked calls, the less intrusive technique I 
> found are uprobes, which is linux-specific. And at the opposite, there are 
> user-space binary code instrumentation libraries such as dyninst that 
> modify the code at run time...
>
> So I am wondering if anyone here has any thoughts on this subject, that 
> doesn't seem to be solved for Go programs.
>
> Thanks!
>
> Julio
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.