Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752165AbdGEVM0 (ORCPT ); Wed, 5 Jul 2017 17:12:26 -0400 Received: from mail-oi0-f45.google.com ([209.85.218.45]:35661 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751659AbdGEVMY (ORCPT ); Wed, 5 Jul 2017 17:12:24 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170705050500.GA72383@beast> From: Arnd Bergmann Date: Wed, 5 Jul 2017 23:12:23 +0200 X-Google-Sender-Auth: PunkXxx_hJhBa3NN-swy_hdpZwg Message-ID: Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 To: Linus Torvalds Cc: Kees Cook , Linux Kernel Mailing List , Ard Biesheuvel , 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: 2240 Lines: 46 On Wed, Jul 5, 2017 at 9:07 PM, Linus Torvalds wrote: > 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? It sounds useful to me, at least as a compile-time option. My first thought was to move it under CONFIG_UBSAN, which has related undefined-behavior checks. I see that we are disabling the -Wmaybe-uninitialized warning with UBSAN at the moment to shut up lots of warnings introduced by UBSAN, and that could mean one of two things: either gcc gets a lot worse at tracing the state of variables with UBSAN, or UBSAN causes it to warn about anything that it can't prove to be initialized rather than making some reasonable assumptions about calls to external functions. If the latter is true, it might be enough to just initialize the ones we would warn about with UBSAN. >From what I can tell, there are four main cases of local variables: a) the most common one should be those that gcc can prove to be initialized at the first use. Adding a zero-initialization would be pointless here. b) Those that gcc can prove to be used uninitialized, and it warns about with -Wuninitialized. This sounds like something that -fsanitize=undefined should handle, but I could not find any information about it actually doing that. c) The ones that require knowledge of multiple translation units or functions it decided not to inline, so gcc intentionally doesn't warn about them (unlike smatch). d) The ones that gcc cannot prove to be in any of the above categories (see: halting problem) and warns about with -Wmaybe-uninitialized The last two seem like candidates for implicit zero-initialization, while for b) one could argue that this should be treated like some other undefined behavior and just trap (e.g. gcc now turns code paths it knows to cause divide-by-zero into a single trapping instruction and skips the math leading up to it). Or you could argue that gcc shouldn't do that for other undefined behavior either. Arnd