Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753357AbdGEUko (ORCPT ); Wed, 5 Jul 2017 16:40:44 -0400 Received: from mail-it0-f48.google.com ([209.85.214.48]:37007 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752179AbdGEUkn (ORCPT ); Wed, 5 Jul 2017 16:40:43 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170705050500.GA72383@beast> From: Ard Biesheuvel Date: Wed, 5 Jul 2017 21:40:42 +0100 Message-ID: Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 To: Linus Torvalds Cc: Kees Cook , Linux Kernel Mailing List , Arnd Bergmann , Jean Delvare Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2162 Lines: 44 On 5 July 2017 at 20:07, Linus Torvalds wrote: > Hmm. Completely unrelated comment, and this may not be a gcc 'plugin' > issue as much as a more general gcc question, but I suspect a plugin > could do it. > > For the kernel, we already really ignore some of the more idiotic C > standard rules that introduce pointless undefined behavior: things > like the strict aliasing rules are just insane, and the "overflow is > udnefined" is bad too. So we use > > -fno-strict-aliasing > -fno-strict-overflow > -fno-delete-null-pointer-checks > > to basically say "those optimizations are fundamentally stupid and > wrong, and only encourage compilers to generate random code that > doesn't actually match the source code". > > And I suspect one other undefined behavior is the one we _try_ to warn > about, but where the compiler is not always good enough to give valid > warnings - uninitialized automatic variables. > > Maybe we could have gcc just always initialize variables to zero. Not > just static ones, but the automatic variables too. And maybe it > wouldn't generate much extra code, since gcc will see the real > initialization, and the extra hardening against random behavior will > just go away - so this might be one of those cheap things where we > just avoid undefined behavior and avoid leaking old stack contents. > At the language level, I would be surprised if the compiler exploits this as undefined behaviour, i.e., that it would assume a convenient [for the compiler] fixed value for a variable in cases where it can prove that it has not been initialised. And at the logical level, zero may not always be a suitable default, this highly depends on the particular code sequence. So while I think it may be useful for robustness, to avoid erratic behavior or exploitable interactions between different parts of the code, my estimation is that it wouldn't make a great deal of difference, given that the logic that allows the compiler to 'see the real initialization' is the same logic that warns us if it is lacking, and so in a warning free build, no init sequences should have been emitted to begin with.