Suggestion: ftrivial-auto-var-init=whatever by default
Hi: Bugs due to the use of uninitialized memory are rampant, not only in the kernel where it is extremely dangerous but it is even more widespread in userspace code. I suggest to: Use -ftrivial-auto-var-init=pattern during LEAP development stage, and -ftrivial-auto-var-init=zero in release builds and tumbleweed or some different flag combination depending on which project we are.. staging vs published trees or somethin.. If there is any heinous performance or code size regression on any component this could be disabled on a per-package basis or use__attribute__((uninitialized)) in the offending code. Cheers.
Am 25.05.22 um 22:18 schrieb Cristian Rodríguez:
Bugs due to the use of uninitialized memory are rampant, not only in the kernel where it is extremely dangerous but it is even more widespread in userspace code.
I suggest to:
Use -ftrivial-auto-var-init=pattern during LEAP development stage, and -ftrivial-auto-var-init=zero in release builds and tumbleweed or some different flag combination depending on which project we are.. staging vs published trees or somethin..
Not sure about this. With modern C++ this is rarely an issue anymore because of constructors, and there is static analysis [1,2,3] and the MemorySanitizer to find such issues [4,5] in both C and C++.
If there is any heinous performance or code size regression on any component this could be disabled on a per-package basis or use__attribute__((uninitialized)) in the offending code.
Of course heinous regressions will stand out, but what if it's “just” 10–20%? I don't regularly check the size of my packages or do precise benchmarks. The same is probably true for other maintainers. To be fair, optimizers can likely throw out most of these initializations. But we have simply no infrastructure to monitor such regressions. If this would make a large class of UB in C/C++ disappear I'd say let's go for it, but it's just one in a very long list [6], and in my experience (which is mostly C++ to be fair) not the most pressing issue, where uninitialized memory is relatively rare compared to lifetime issues and data races. (We actually have bug statistics for this.) In my view this makes probably more sense on packages that have a history with such issues, are written in C, or are security-relevant. But my view may be skewed, because I mostly maintain packages where performance is highly relevant and security not so much, so that I mostly prefer zero-cost tools like compiler warnings, or tests on sanitizer builds. Aaron [1] <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized> [2] <https://clang.llvm.org/docs/DiagnosticsReference.html#wconditional-uninitialized> [3] <https://clang.llvm.org/docs/analyzer/checkers.html#core-uninitialized-arraysubscript-c> [4] <https://github.com/google/sanitizers/wiki/MemorySanitizer> [5] <https://clang.llvm.org/docs/MemorySanitizer.html> [6] <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>, Annex J.2 “Undefined behavior”. There is no such official list for C++.
Aaron Puchert <aaronpuchert@alice-dsl.net> writes:
Am 25.05.22 um 22:18 schrieb Cristian Rodríguez:
Bugs due to the use of uninitialized memory are rampant, not only in the kernel where it is extremely dangerous but it is even more widespread in userspace code.
I suggest to:
Use -ftrivial-auto-var-init=pattern during LEAP development stage, and -ftrivial-auto-var-init=zero in release builds and tumbleweed or some different flag combination depending on which project we are.. staging vs published trees or somethin..
Not sure about this. With modern C++ this is rarely an issue anymore because of constructors, and there is static analysis [1,2,3] and the MemorySanitizer to find such issues [4,5] in both C and C++.
There's still a ton of old C++ around that never went for these modern concepts and in C you have nothing comparable. Also, memory sanitizers like ASAN, MSAN and UBSAN really only help if you reach the problematic code in your test suite. I have seen code bases with not enough test coverage and unsurprisingly, all the memory issues were in the code paths not covered by tests.
If there is any heinous performance or code size regression on any component this could be disabled on a per-package basis or use__attribute__((uninitialized)) in the offending code.
Of course heinous regressions will stand out, but what if it's “just” 10–20%? I don't regularly check the size of my packages or do precise benchmarks. The same is probably true for other maintainers. To be fair, optimizers can likely throw out most of these initializations. But we have simply no infrastructure to monitor such regressions.
If this would make a large class of UB in C/C++ disappear I'd say let's go for it, but it's just one in a very long list [6], and in my experience (which is mostly C++ to be fair) not the most pressing issue, where uninitialized memory is relatively rare compared to lifetime issues and data races. (We actually have bug statistics for this.)
In my view this makes probably more sense on packages that have a history with such issues, are written in C, or are security-relevant. But my view may be skewed, because I mostly maintain packages where performance is highly relevant and security not so much, so that I mostly prefer zero-cost tools like compiler warnings, or tests on sanitizer builds.
Having some data wrt package size and runtime overhead would be great for driving this change. I also would agree with Aaron that C code would be a good initial target but it would be probably far simpler to enable this everywhere, as opt-in would probably result in very small adoption. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
participants (3)
-
Aaron Puchert -
Cristian Rodríguez -
Dan Čermák