From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id D57D36B025E for ; Fri, 15 Jul 2016 15:14:26 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id f126so21727555wma.3 for ; Fri, 15 Jul 2016 12:14:26 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com. [2a00:1450:400c:c09::236]) by mx.google.com with ESMTPS id yk9si2236999wjc.280.2016.07.15.12.14.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jul 2016 12:14:24 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id o80so42133391wme.1 for ; Fri, 15 Jul 2016 12:14:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1468609254.32683.34.camel@gmail.com> References: <1468446964-22213-1-git-send-email-keescook@chromium.org> <1468446964-22213-3-git-send-email-keescook@chromium.org> <20160714232019.GA28254@350D> <1468609254.32683.34.camel@gmail.com> From: Kees Cook Date: Fri, 15 Jul 2016 12:14:23 -0700 Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: "kernel-hardening@lists.openwall.com" Cc: Balbir Singh , LKML , Rik van Riel , Casey Schaufler , PaX Team , Brad Spengler , Russell King , Catalin Marinas , Will Deacon , Ard Biesheuvel , Benjamin Herrenschmidt , Michael Ellerman , Tony Luck , Fenghua Yu , "David S. Miller" , "x86@kernel.org" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Andy Lutomirski , Borislav Petkov , Mathias Krause , Jan Kara , Vitaly Wool , Andrea Arcangeli , Dmitry Vyukov , Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux-ia64@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" , sparclinux , linux-arch , Linux-MM On Fri, Jul 15, 2016 at 12:00 PM, Daniel Micay wrote: >> This could be a BUG, but I'd rather not panic the entire kernel. > > It seems unlikely that it will panic without panic_on_oops and that's > an explicit opt-in to taking down the system on kernel logic errors > exactly like this. In grsecurity, it calls the kernel exploit handling > logic (panic if root, otherwise kill all process of that user and ban > them until reboot) but that same logic is also called for BUG via oops > handling so there's only really a distinction with panic_on_oops=1. > > Does it make sense to be less fatal for a fatal assertion that's more > likely to be security-related? Maybe you're worried about having some > false positives for the whitelisting portion, but I don't think those > will lurk around very long with the way this works. I'd like it to dump stack and be fatal to the process involved, but yeah, I guess BUG() would work. Creating an infrastructure for handling security-related Oopses can be done separately from this (and I'd like to see that added, since it's a nice bit of configurable reactivity to possible attacks). -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org