From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751714AbcGOTO2 (ORCPT ); Fri, 15 Jul 2016 15:14:28 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:38492 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751555AbcGOTOZ (ORCPT ); Fri, 15 Jul 2016 15:14:25 -0400 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 X-Google-Sender-Auth: 8JUGQRJBJhH7J5jiTer-mJ5InMc Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy 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 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 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