Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752368AbdGETHp (ORCPT ); Wed, 5 Jul 2017 15:07:45 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:34811 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751700AbdGETHo (ORCPT ); Wed, 5 Jul 2017 15:07:44 -0400 MIME-Version: 1.0 In-Reply-To: <20170705050500.GA72383@beast> References: <20170705050500.GA72383@beast> From: Linus Torvalds Date: Wed, 5 Jul 2017 12:07:42 -0700 X-Google-Sender-Auth: NHkQyl8yLIyIzFuYYTDlBfPG7Xc Message-ID: Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 To: Kees Cook Cc: Linux Kernel Mailing List , Ard Biesheuvel , 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: 1761 Lines: 41 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. Yes, yes, you'd still have the uninitialized variable warning, but that doesn't catch the case where you pass a structure pointer to a helper that is *supposed* to fill it in, but misses a field or just misses padding. And maybe I'm wrong, and maybe it would generate a lot of really bad extra zeroing and wouldn't be acceptable for most people, but I *think* this might be one of those things where we might get some extra belt and suspenders kind of hardening basically for free.. Comments? Linus