Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754852AbbK0Pau (ORCPT ); Fri, 27 Nov 2015 10:30:50 -0500 Received: from r00tworld.com ([212.85.137.150]:44161 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754792AbbK0Pal (ORCPT ); Fri, 27 Nov 2015 10:30:41 -0500 From: "PaX Team" To: Linus Torvalds , Ingo Molnar Date: Fri, 27 Nov 2015 16:29:55 +0100 MIME-Version: 1.0 Subject: Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Reply-to: pageexec@freemail.hu CC: kernel-hardening@lists.openwall.com, Mathias Krause , "linux-kernel@vger.kernel.org" , Kees Cook , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , x86-ml , Arnd Bergmann , Michael Ellerman , linux-arch@vger.kernel.org, Emese Revfy Message-ID: <565876F3.21515.18F8DF8F@pageexec.freemail.hu> In-reply-to: <20151127080554.GB24991@gmail.com> References: <1448401114-24650-1-git-send-email-keescook@chromium.org>, <5656F7A2.738.131F89C0@pageexec.freemail.hu>, <20151127080554.GB24991@gmail.com> X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (r00tworld.com [212.85.137.150]); Fri, 27 Nov 2015 16:29:48 +0100 (CET) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3530 Lines: 70 On 27 Nov 2015 at 9:05, Ingo Molnar wrote: > * PaX Team wrote: > > > On 26 Nov 2015 at 11:42, Ingo Molnar wrote: > > > > > * PaX Team wrote: > > that's actually not the typical case in my experience, but rather these two: > > > > 1. initial mistake: someone didn't actually check whether the given object can > > be __read_only > > > > 2. code evolution: an object that was once written by __init code only (and > > thus proactively subjected to __read_only) gets modified by non-init code > > due to later changes > > > > what you described above is a third case where there's a latent bug to begin > > (unintended write) with that __read_only merely exposes but doesn't create > > itself, unlike the two cases above (intended writes getting caught by wrong use > > of __read_only). > > You are right, I concede this part of the argument - what you describe is probably > the most typical way to get ro-faults. > > I do maintain the (sub-)argument that oopsing or relying on tooling help years > down the line is vastly inferior to fixing up the problem and generating a > one-time stack dump so that kernel developers have a chance to fix the bug. The > sooner we detect and dump such information the more likely it is that such bugs > don't get into end user kernel versions. i don't see the compile time vs. runtime detection as 'competing' approaches, both have their own role. in general, i think it's safe to say that compile time problem detection is preferred to the runtime one since it subjects less users to the side effects of the bug. runtime detection is needed to augment (even complete) the coverage that compile time detection may not be able to provide. that said, for __read_only related problems the compiler can actually do a pretty good job, basically it could detect most of them except special cases where the 'bad' write is somehow hidden from it. the only examples i recall are like the one that Mathias already mentioned where the 'bad' write was done from asm code or out-of-kernel code (think UEFI runtime services) that is obviously not visible to the compiler (the resume/mmu_cr4_features problem also happens to be an example where runtime detection did not help due to the circumstances). so let me summarize how i expect the runtime detection part to work: 1. in normal use any write attempt to read-only kernel data should only be reported as usual (the oops info already has rip/cr2/backtrace), but no smart recovery attempts should be made since they may end up actually helping a real exploit attempt. 2. if necessary for debugging purposes (i.e., when the above reporting mechanism didn't produce the necessary logs and the problem is reproducible and wasn't an attack), a kernel command line option can be used to make an attempt at smart recovery instead of oopsing (but the same information would still be reported of course). for this smart recovery we differ(ed?) in opinion, i say that allowing the write in this case (vs. ignoring it) is the least likely to introduce a logic bug (and its cascading effects) since the expected problem is to be case #1 or #2 above (i.e., the write is intended but prevented by __read_only). -- 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/