From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1520310629; cv=none; d=google.com; s=arc-20160816; b=rg7revYv27BDZHQ3M9v3eUXHSOR47pCH9xMfhrVaD7qFBR6YUxcf2NXuhPmTUEzQtZ btEFWzTnCzNAt8o3G5xSnlLb3sH/qmKF49wEPEkp/F3RpTKCgEOcFUi5ItkenqYRNddu 1rSdDIMT1Sg5sQXqWCozj5VtFjIhe7617S3v7kzMIVMWgpPLOeVayGZThElG3iiTMLvR JTH2NvUHLoBgUVmzxzt2S0k3dAbkeY2rUDUPHBM2UsB1+fE5GH9Q+4gMM46MdpcLOgtd 5HFcHbyojq0kPWMC7VrW6FWLvctsMdaCrjerOrCGcGZeeV4CMWG9u2Vep8CjcnUF/mO6 sIOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=Vp7GScJjZzYKuQvVc9F8mx/OyV8QNOxzf4xNM9Kd0gY=; b=qrPhlYqIblGaf3A9CKYuK3IJogCT4HUHrDLeUCH8QBmOCIj7dBidXCqYYbNBGMkk41 H/FwHw7oLab93XwhMOCEHBU5/Le+Fv+Dc7QQfJ14z4EOBNuX6yc80YoJCaH6SNHXYPAY KFE4xbsXPetmI86zI4amVJ3IyXgEW4VZm8eqeE7DmOLdejwbznVh5CMhUQWQL6/JMgjn jxea4M2CUWBUWrNXNQVRH1aW/iw/582rrpMW0+IjzqMr3csQUDMtTURcCish6F1N55GX 3aAlDv2VtnLPs9E0aOk3BghbdxIbO/1y/NSg81W4U/ie+LBQFRV1TMP2ZMUoXSVb6QXb t66g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=anSaK0yG; dkim=pass header.i=@linux-foundation.org header.s=google header.b=UWVuSFb8; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=linus971@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=anSaK0yG; dkim=pass header.i=@linux-foundation.org header.s=google header.b=UWVuSFb8; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=linus971@gmail.com X-Google-Smtp-Source: AG47ELsk3ea5C4Gk/fSSMFkkj5iWIMet7BfYL2TGncC+ttgKP2MZBSZULeozH4YKAcV1qwVxhT5SOKGTJHBtMuJ8jV0= MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: References: <1520107232-14111-1-git-send-email-alex.popov@linux.com> <1520107232-14111-5-git-send-email-alex.popov@linux.com> From: Linus Torvalds Date: Mon, 5 Mar 2018 20:30:28 -0800 X-Google-Sender-Auth: WrzN1dYeWSKbnrQsp2zbQpbVDM8 Message-ID: Subject: Re: [PATCH RFC v9 4/7] x86/entry: Erase kernel stack in syscall_trace_enter() To: Kees Cook Cc: Dave Hansen , Alexander Popov , Kernel Hardening , PaX Team , Brad Spengler , Ingo Molnar , Andy Lutomirski , Tycho Andersen , Laura Abbott , Mark Rutland , Ard Biesheuvel , Borislav Petkov , Richard Sandiford , Thomas Gleixner , "H . Peter Anvin" , Peter Zijlstra , "Dmitry V . Levin" , Emese Revfy , Jonathan Corbet , Andrey Ryabinin , "Kirill A . Shutemov" , Thomas Garnier , Andrew Morton , Alexei Starovoitov , Josef Bacik , Masami Hiramatsu , Nicholas Piggin , Al Viro , "David S . Miller" , Ding Tianhong , David Woodhouse , Josh Poimboeuf , Steven Rostedt , Dominik Brodowski , Juergen Gross , Greg Kroah-Hartman , Dan Williams , Mathias Krause , Vikas Shivappa , Kyle Huey , Dmitry Safonov , Will Deacon , Arnd Bergmann , X86 ML , LKML Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1593947986518331727?= X-GMAIL-MSGID: =?utf-8?q?1594161238713883938?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Mar 5, 2018 at 4:56 PM, Kees Cook wrote: > On Mon, Mar 5, 2018 at 1:40 PM, Linus Torvalds > wrote: >> and we already obviously limit that kind of broken behavior >> with -fwrapv and -fno-strict-alias. > > And -fno-delete-null-pointer-checks, and and and.... :P Indeed. > The recent discussions on minimum compiler version underscore the fact > that people move forward on compilers _very_ slowly. Yes. At the same time, things like that are kind of like a config option for hardening - it's not like everybody absolutely needs to have the compiler support, but people who want it can. Sure, it limits us in some ways (ie we can't just say "we _depend_ on automatic variables being zero"), but as long as it's not a huge maintenance burden, it probably doesn't much matter. >> And it doesn't necessarily generate any worse code. > > I agree, though some performance-sensitive subsystem (e.g. networking) > get very defensive about an always-on stack initialization[2]. No > matter what happens with this kind of automatic initialization, I > suspect it's going to have to stay a build-time option to let some > people opt-out of it. I do think that having some way of marking "this variable really doesn't need zeroing" would be fine. Then peope'd *think* about the fact that you're passing an actual uninitialized piece of memory around, and people could be careful with them. And the places that would actually want that should show up like a sore thumb in a profile. And if they don't, then clearly the zeroing can't be much of an issue, can it? > Another case is that this series provides actual stack probing to > detect VLA abuse. This is less of an issue now with VMAP_STACK, and > I've had VLA removal on the long-term goal list for the kernel for a > while now, but the probing does work... I was actually hoping that the clang people would get rid of those, but they only seemed to care about VLA's in structures, not about them in general ;( I detest VLA's, we really shouldn't use them. I'm sorry we have any. Linus