Hello, Please see: -> http://www.openwall.com/lists/kernel-hardening/2018/02/27/33 -> http://www.openwall.com/lists/kernel-hardening/2018/02/27/41 Some time back, a proposal to zero(0) initialize various automatic stack variables(inc arrays/structs/etc.) inside kernel was proposed based on an experimental glibc patch, with an intention to remove kernel information leakage issues. As from the reply, it would be nice to have four options/features available from the compiler, from least to most performance impact: - initialize padding to zero when static initializers are used (this would make foo = { .field = something }; identical to memset(&foo, 0, sizeof(foo)); foo.field = something for all structures, but now, any structures with padding _must_ use the latter to be safe, which is highly error-prone). - initialize all uninitialized variables that contain a structure marked with a special attribute (e.g. __attribute__((force_initialize)) ). - initialize all uninitialized variables that are passed by reference (see GCC_PLUGIN_STRUCTLEAK_BYREF_ALL). - initialize all uninitialized variables (-finit-local-vars seems to do this) The advent of h/w vulnerabilities like Spectre and Meltdown and more recently L1TF has not only opened a new research area but has also reiterated the importance of initializing memory bytes with known values. Also see: -> https://googleprojectzero.blogspot.com/2018/06/detecting-kernel-memory-disclosure.html Would it be possible to introduce new gcc(1) command-line options to initialize automatic stack variables(inc arrays/structs/etc.) of a program? Thank you.
http://wiki.c2.com/?TheKenThompsonHack
On Mon, 3 Sep 2018, pjp at fedoraproject dot org wrote: > As from the reply, it would be nice to have four options/features available > from the compiler, from least to most performance impact: > > - initialize padding to zero when static initializers are used (this would > make foo = { .field = something }; identical to memset(&foo, 0, > sizeof(foo)); foo.field = something for all structures, but now, any > structures with padding _must_ use the latter to be safe, which is highly > error-prone). Presumably that sort of thing would need to come with a guarantee that SRA, structure assignment etc. preserve padding (rather than padding contents potentially being lost if a structure is subject to SRA)? (Both are effectively treating padding like additional named fields for the purposes of code generation but without affecting what fields the front end associates initializers with. I'd expect the performance costs of such guarantees associated with padding to be small.)
Similar options under review for LLVM -> https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html
To give an update, upstream Clang now supports force initialization of stack variables under the -ftrivial-auto-var-init flag. -ftrivial-auto-var-init=pattern initializes local variables with a 0xAA pattern (actually it's more complicated, see https://reviews.llvm.org/D54604) -ftrivial-auto-var-init=zero provides zero-initialization of locals. This mode isn't officially supported yet and is hidden behind an additional -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang flag. This is done to avoid creating a C++ dialect where all variables are zero-initialized. Starting v5.2, Linux kernel has a CONFIG_INIT_STACK_ALL config that performs the build with -ftrivial-auto-var-init=pattern. This one isn't widely adopted yet, partially because initializing locals with 0xAA isn't fast enough. Linus Torvalds is quite positive about zero-initializing the locals though, see https://lkml.org/lkml/2019/7/30/1303 So having a flag similar to -ftrivial-auto-var-init=zero in GCC will be appreciated by the Linux kernel community.
*** Bug 94855 has been marked as a duplicate of this bug. ***
So, based on the previous discussion on the LLVM option -ftrivial-auto-var-init=[uninitialized|pattern|zero] we can see: -ftrivial-auto-var-init=pattern might not be a good idea due to the following: 1. performance data is not good; 2. doesn't really help improve the general situation. People see it as a debugging tool, not a "improve code quality and improve the life of kernel developers" tool. (Per Linus) On the other hand, -ftrivial-auto-var-init=zero might be helpful to improve code quality and improve the life fo kernel developers. At the same time, a new variable attribute might be needed at the same time along with -ftrivial-auto-var-init=zero: __attribute((uninitialized) to mark variables that are uninitialized intentionally for performance purpose. In a summary, in GCC, we should provide: 1. add a new GCC option: -ftrivial-auto-var-init to initialize trivial auto variable to zero. 2. provide a new attribute for variable: __attribute((uninitialized) to mark variables that are uninitialized intentionally for performance purpose.
Confirmed.
*** Bug 70069 has been marked as a duplicate of this bug. ***
-ftrivial-auto-var-init=[uninitialized|pattern|zero] Add initializations to automatic variables.