paulf38

I always assume that anyone that says that something is a false positive without providing any rigorous proof has confirmation bias and are sadly deluding themselves about their ability and the correctness of their code.

Valgrind has a long history, it is now about 23 years old. Over that period it has used several systems to host the source repo, web site and bug database.

At the time of writing, sourceware hosts both the web site and git repo, sourceforge hosts the mailing lists and KDE hosts our bugzilla bug database.

Yes indeed. The backdoor author did try to claim that it was a false positive (and I’m sure that a very depressingly large number of people would happily go along with such a claim even without a scrap of evidence).

The error was related to the use of the frame pointer. Optimised code does not use RBP as the frame pointer, only using RSP for stack addresses. The XZ backdoor code assumed that the stack used this layout. The RedHat regression tests use debug builds that do use the frame pointer. The result was the backdoor code writing below the bottom of the stack.

I suspect also that Valgrind is unique in finding issues like this. Other tools do not check all memory accesses before main. Valgrind loads and runs the test binary from the very beginning and thus it detected errors in the ifunc code used by XZ that executed very early on during ld.so loading and symbol resolution.

C is the language that benefits the most from tools like Valgrind. It's just so easy in C to write code with memory faults.

Memcheck (the main tool) has shortcomings (very slow, does not detect all kinds of errors). Its strongest point is that it does not need an instrumented build. That can be particularly important if you have issues in 3rd party libraries that you can't build. Its other strong point is that it checks for both addressability and initialisedness at the same time.

My favourite feature is using GDB with Valgrind+vgdb. That allows you to see what memory is addressable and/or initialised from within GDB.

If any macOS experts could help with this port it would be most welcome.

Apple have been making big changes that keep breaking things and Valgrind has not kept up. Louis Brunner has done an amazing job more or less single handedly managed to keep the basic flow working.

That's a 15 year old blog post and the linked GH repo hasn't been updated.

That's quite nice. There is a small risk that the client request mechanism might change . The headers don't change much - mostly when a new platform gets added. Go is only targeting amd64 and arm64.

This isn't so much about leaks. The most important thing that this will enable is correct analysis of uninitialised memory. Without annotation memory that gets recycled will not be correctly poisoned. I imagine that it will also be useful for the other tools (except cachegrind and callgrind).