Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go has added Valgrind support

go-review.googlesource.com

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Go has added Valgrind support

#131

Post by cirelli94 »

DishyDev wrote: post #70

Very cool. Should flush out a few bugs. I'd be interested to know why Valgrind vs the Clang AddressSanitizer and MemorySaniziter. These normally find more types of errors (like use-after-return) and I find it significantly faster than Valgrind.

I'm interested too. I'm using a Go program that call a cpp library with SWING and I was interested in find out if that library had a memory leak, or maybe the SWING wrap I wrote. But this kind of problem can't be detected via pprof, so I tought, what if Go support Valgrind?? and find out this changes.

I'm not sure if this will work though, will it @bracewel?

Re: Go has added Valgrind support

#132

Post by HALtheWise »

on_the_beach wrote: post #114
bracewel wrote: post #71

Author of the linked CL here: we added this mostly so that we could abuse the memory initialization tracking to test the constant-time-ness of crypto code (similar to what BoringSSL does, proposed by agl around fifteen years ago: https://www.imperialviolet.org/2010/04/01/ctgrind.html ), which is an annoyingly hard property to test. We're hoping that there are also a bunch of other interesting side-effects of enabling…

This is super cool. Hopefully it will flush out other issues in Go too. But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance? I mean, you want to show constant time of your crypto functions, why not just directly measure the time under lots of inputs? (and maybe background Garbage Collection and OS no…

Feeding random inputs to a crypto function is not guaranteed to exercise all the weird paths that an attacker providing intentionally malicious input could access. For example, a loop comparing against secret data in 32 bit chunks will take constant time 99.99999999% of the time, but is still a security hole because an attacker learns a lot from the one case where it returns faster. Crypto vulnerabilities often take the form of very specifically crafted inputs that exploit some mathematical property that's very unlikely from random data.

Re: Go has added Valgrind support

#133

Post by 1718627440 »

acidx wrote: post #124
1718627440 wrote: post #119

Earlier quoted context omitted.

Valgrind is way faster and can be attached to a running program.

Programs running under any Valgrind tool will be executed using a CPU emulator, making it quite a bit slower than, say, running the instrumented binaries as required by sanitizers; it's often an order of magnitude slower, but could be very well be close to two orders of magnitude slower in some cases. This also means that it just can't be attached to any running program, because, well, it's emulating a whole CPU to t…

You're right and I was wrong, but in my experience Valgrind has been way faster then the AdressSanitizer. I don't perceive a difference with Valgrind, while ASan makes the program slower around 10x.

Re: Go has added Valgrind support

#134

Post by pjmlp »

spookie wrote: post #102
pjmlp wrote: post #48

Earlier quoted context omitted.

It would be another scenario to use as ammunition for "see you can't implement a language toolchain without using C" , usually voiced by folks without background in compiler design, and understanding that most of the time that is a decision that spurs out of convenience and nothing else. Assembly isn't that hard, those of us that grown around 8 bit home computers were writing Z80 and 6502 Assembly aged 10 - 12 years…

Isn't Valgrind written in C?

Yes, but the goal of this is integration, not Rewrite in Go for Valgrind.

Re: Go has added Valgrind support

#135

Post by pjmlp »

9rx wrote: post #109
tasn wrote: post #106

Earlier quoted context omitted.

If I had to guess: because Rust engineers are like every other engineer that reads HN. They read stories, sometimes comment, and share from their own experience. Rust and Go were created roughly at the same time and are more directly comparable than e.g. Go and Ruby, so you don't see Ruby people writing about not having to use Valgrind. This means you'll see more comments from Rust devs than others in Go threads. At…

> and are more directly comparable than e.g. Go and Ruby Why do you say that? The original Go announcement made it abundantly clear that it was intended to be like a dynamically-typed language, but faster. It is probably more like Python than Ruby, as it clearly took a lot of ideas from Python, but most seem to consider those languages to be in the same hemisphere anyway. Beyond maybe producing complied binaries, whi…

What?

Here is Rob Pike blog post about instead of getting C and C++ developers, they got the dynamic language folks.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Re: Go has added Valgrind support

#137

Post by rwmj »

hedora wrote: post #128
ben-schaaf wrote: post #72

Earlier quoted context omitted.

IME Helgrind does an great job finding concurrency issues.

tsan from LLVM works a bit better in my experience. I still like valgrind in general though!

For fuzzing we don't use valgrind, but use Clang + ASan instead. All these tools have their niches.

Re: Go has added Valgrind support

#138

Post by scheme271 »

thwarted wrote: post #126
on_the_beach wrote: post #114

Earlier quoted context omitted.

This is super cool. Hopefully it will flush out other issues in Go too. But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance? I mean, you want to show constant time of your crypto functions, why not just directly measure the time under lots of inputs? (and maybe background Garbage Collection and OS no…

Because "constant time" here means algorithms that are O(1), rather than O(n). This isn't about wall-clock execution time, it's about avoiding the number of operations performed being based on attributes of the input.

I think it's more complicated than that. Certain things like branches, comparisons, and some other operations may not be constant time especially if you consider interactions with prior code. It's clearly possible just really difficult to get right.

Re: Go has added Valgrind support

#139

Post by 9rx »

pjmlp wrote: post #135
9rx wrote: post #109

Earlier quoted context omitted.

> and are more directly comparable than e.g. Go and Ruby Why do you say that? The original Go announcement made it abundantly clear that it was intended to be like a dynamically-typed language, but faster. It is probably more like Python than Ruby, as it clearly took a lot of ideas from Python, but most seem to consider those languages to be in the same hemisphere anyway. Beyond maybe producing complied binaries, whi…

What? Here is Rob Pike blog post about instead of getting C and C++ developers, they got the dynamic language folks. https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

You hit the wrong reply button. It was the sibling comment that thought that Go attracted C developers.

Re: Go has added Valgrind support

#140

Post by 9rx »

tasn wrote: post #105
9rx wrote: post #92

Earlier quoted context omitted.

> but rather how happy everyone on the thread is (which means it's more useful than it should be due to a failure with the ecosystem). More likely Go users are just happy in general. The Rust users always come across as being incredibly grumpy for some reason, which may be why that happiness — or what would be considered normalcy in any other venue — seems to stand out so much in comparison. > We link against [...] O…

Rust has rustls, we need to use OpenSSL for a very specific set of reasons unfortunately, but rustls is great and most people can just use that. Also, I had no idea it was added because of constant time crypto that was shared after I wrote my top level comment.

I'm not entirely clear here. Are you saying that the failure of the Go ecosystem was in not building on rusttls (which didn't exist at the time), or are you saying that the failure of the ecosystem was in you not stopping to think before writing your comment?
Post reply on HN