Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941820AbcJEWRK (ORCPT ); Wed, 5 Oct 2016 18:17:10 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:36338 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936544AbcJEWRF (ORCPT ); Wed, 5 Oct 2016 18:17:05 -0400 MIME-Version: 1.0 In-Reply-To: References: <20161005054407.GC7297@1wt.eu> <20161005190604.GA8116@1wt.eu> From: Kees Cook Date: Wed, 5 Oct 2016 15:17:02 -0700 X-Google-Sender-Auth: j-QwC-AWKr1ws-pR5_ORzPo3NnQ Message-ID: Subject: Re: BUG_ON() in workingset_node_shadows_dec() triggers To: Linus Torvalds Cc: Willy Tarreau , Paul Gortmaker , Johannes Weiner , Andrew Morton , Antonio SJ Musumeci , Miklos Szeredi , Linux Kernel Mailing List , stable 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: 2051 Lines: 44 On Wed, Oct 5, 2016 at 2:46 PM, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 2:14 PM, Kees Cook wrote: >> Now, it can be argued that killing the process part should be >> configurable and that the code should be written to handle a WARN and >> clean up and error out nicely. But I still want to retain the "kill >> the process immediately" behavior in some capacity. > > If "some capacity" is "can't do user space accesses", we could easily > force a SIGKILL of the current process. It won't die immediately in > the kernel, but it won't be returning to user space either. With my more paranoid desires, I would prefer to keep "stop kernel execution with the state set up by this process", not just "make the process never return to user-space". I would need to meditate on whether what I really want is just "panic on Oops" or not, though. Right now, for example, I don't use panic-on-oops when running lkdtm tests since each test gets (correctly) killed and the Oops can be examined for the expected failure mode, all without bringing down the entire system. > The problem with the immediate kill is that it can be in interrupt > context, or just holding arbitrary locks. And it's hard to even tell > dynamically (sometimes you can see it: with preemption enabled you can > tell "am I in a non-preempt area", for example, but it ends up > depending on config options). Yeah, I've seen some hilarious failure modes while building lkdtm tests for various kernel self-protections. > And *if* we make BUG() actually do something sane (non-trapping), we > can easily make it be generic, not arch-specific. In fact, I'd > implement it by just adding a "handle_bug()" in kernel/panic.c... Yeah, I'm not sure what the right next step would be. Do we need a new set of functions between WARN and BUG? Or maybe extract the process-killing logic on a per-arch level and make it a specific API so that it can be explicitly called as part of error-handling? Hmm -Kees -- Kees Cook Nexus Security