Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751599AbbK2IFM (ORCPT ); Sun, 29 Nov 2015 03:05:12 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:33867 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750915AbbK2IFK (ORCPT ); Sun, 29 Nov 2015 03:05:10 -0500 Date: Sun, 29 Nov 2015 09:05:05 +0100 From: Ingo Molnar To: Andy Lutomirski Cc: Kees Cook , Linus Torvalds , PaX Team , "kernel-hardening@lists.openwall.com" , Mathias Krause , "linux-kernel@vger.kernel.org" , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , x86-ml , Arnd Bergmann , Michael Ellerman , linux-arch , Emese Revfy Subject: Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Message-ID: <20151129080505.GA23721@gmail.com> References: <1448401114-24650-1-git-send-email-keescook@chromium.org> <565595F5.32536.DB9FE75@pageexec.freemail.hu> <20151126085425.GA29848@gmail.com> <20151127075959.GA24991@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1255 Lines: 31 * Andy Lutomirski wrote: > >> - print a warning and a backtrace, and just mark the page read-write > >> so that the machine survives, but we get notified and can fix whatever > >> broken code > > > > This seems very easy to add. Should I basically reverse the effects of > > mark_rodata_ro(), or should I only make the new ro-after-init section as RW? > > (I think the former would be easier.) > > I'd suggest verifying that the page in question is .data..ro_after_init and, if > so, marking that one page RW. Yes, this was PaX's suggestion as well, and I agree: doing that turns a quite possibly unrecoverable boot/shutdown time or suspend/resume time (suspend is really a special category of 'bootup') crasher oops into a more informative stack dump. These ro related faults tend to trigger when init/deinit is running, and oopsing in those sequences is typically a lot less survivable than say oopsing in a high level system call while not holding locks. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/