On Tue, Jul 30, 2019 at 9:54 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > > On Tue, Jul 30, 2019 at 6:53 AM Alexander Potapenko <gli...@google.com> wrote: > > > > I wonder how hard it should be to make a zero-filling GCC plugin? > > I'm not a big fan of hacking GCC, but it shouldn't differ much from > > the existing GCC plugins that initialize locals. > > The thing is, as long as it's a plugin, I don't think we can rely on > it. The gcc people will rightly just laugh at us if we were to report > a bug with some kernel plugin. > > So I'd like the zeroing of local variables to be a native compiler > option, so that we can (_eventually_ - these things take a long time) > just start saying "ok, we simply consider stack variables to be always > initialized". > > > I've some stale data collected on an x86 QEMU instance. > > For 0x00 stack initialization: > > - hackbench, netperf and parallel Linux build were virtually free > > (slowdown within stdev) > > - for af_inet_loopback the slowdown was ~4% > > For 0xAA stack initialization: > > - netperf and parallel Linux build were free > > - for hackbench the slowdown was ~1.5% > > - for af_inet_loopback the slowdown was ~7% > > So I would expect that we have some special cases where we end up > having arrays (or big structures) on the stack that end up being > critical, and where initializing them is clearly abad idea. > > Then we can verify manually are very much initialized, and that we > could then mark and say "this is uninitialized". > > So when a compiler has an option to initialize stack variables, it > would probably _also_ be a very good idea for that compiler to then > support a variable attribute that says "don't initialize _this_ > variable, I will do that manually". FWIW Clang has __attribute((uninitialized)) already: https://reviews.llvm.org/rL349442 I agree that making it in GCC is easier if initialization itself is implemented as part of GCC.
> But if we in ten years had a kernel model where only allocations and > variables that were _explicitly_ uninitialized, that would be lovely. > > Then you can grep for those and verify that "yes, this is safe". > > We've historically had the reverse model - things are uninitialized by > default, and you have to explicitly initialize them. Turning that on > its head is what I would like to do long-term. > > (For normal allocations that wouldn't be too bad: get rid of > __GFP_ZERO and friends, and instead do __GFP_UNINITIALIZED). There've been concerns about such flags easily going out of control (my original proposal for heap initialization contained such a flag). To some extent their spread can be prevented by build-time checks, but a simple grep can be insufficient, as people will start creating helper functions to allocate with __GFP_UNINITIALIZED. > Again - I don't think we want a world where everything is > force-initialized. There _are_ going to be situations where that just > hurts too much. But if we get to a place where we are zero-initialized > by default, and have to explicitly mark the unsafe things (and we'll > have comments not just about how they get initialized, but also about > why that particular thing is so performance-critical), that would be a > good place to be. > > This, btw, is why I also think that the "initialize with poison" is > pointless and wrong. Yes, it can find bugs, but it doesn't really help > improve the general situation, and people see it as a debugging tool, > not a "improve code quality and improve the life of kernel developers" > tool. This sure makes sense. If this policy is adopted kernel-wide, we won't need any debugging tools for uninit variables, so it's natural to initialize them to zero. > Linus -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg