From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752550AbdGEVtb (ORCPT ); Wed, 5 Jul 2017 17:49:31 -0400 Received: from mail-it0-f51.google.com ([209.85.214.51]:34717 "EHLO mail-it0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752506AbdGEVta (ORCPT ); Wed, 5 Jul 2017 17:49:30 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170705050500.GA72383@beast> From: Kees Cook Date: Wed, 5 Jul 2017 14:49:28 -0700 X-Google-Sender-Auth: WxjxiUJOC_oGLeMsBXTSJf6h7b4 Message-ID: Subject: Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 To: Linus Torvalds 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 On Wed, Jul 5, 2017 at 12:07 PM, 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. > > 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? It is, unfortunately, not free. :( There has been a lot of academic research[1] into finding ways to minimize the impact, but given some of the Linux maintainers refusing even zeroing of APIs that pass stack-based structures[2]. Another thing that has been worked on is porting the stackleak gcc plugin from grsecurity to upstream[3]. This does effective clearing of the stack, but it takes a more holistic approach (and for added fun, it does alloca probes too). Like some of the more comprehensive academic attempts, it sees about a 4% hit (but it's doing more...) I'd love to get the stackleak plugin into upstream (and the work is on-going), but having something try a "lighter" form of this in a gcc plugin would be interesting to experiment with. -Kees [1] e.g. https://www.internetsociety.org/sites/default/files/ndss2017_09-2_Lu_paper.pdf performs only uninitialized on-stack pointer zeroing, and http://www.cs.vu.nl/~giuffrida/papers/safeinit-ndss-2017.pdf shows <5% performance hit with optimization for initializing everything [2] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=getsockname&id=a4467f966f0c70fd232388c05798a84276eef1ef [3] http://openwall.com/lists/kernel-hardening/2017/06/09/14 -- Kees Cook Pixel Security