Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752077AbbK2Pj0 (ORCPT ); Sun, 29 Nov 2015 10:39:26 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:33246 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751922AbbK2PjX (ORCPT ); Sun, 29 Nov 2015 10:39:23 -0500 Date: Sun, 29 Nov 2015 16:39:18 +0100 From: Ingo Molnar To: PaX Team Cc: Linus Torvalds , 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 Subject: Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Message-ID: <20151129153918.GA12215@gmail.com> References: <1448401114-24650-1-git-send-email-keescook@chromium.org> <565876F3.21515.18F8DF8F@pageexec.freemail.hu> <20151129080853.GB23721@gmail.com> <565ADE35.20892.225C67C2@pageexec.freemail.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <565ADE35.20892.225C67C2@pageexec.freemail.hu> 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: 1552 Lines: 36 * PaX Team wrote: > On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > > > > * PaX Team wrote: > > > > > i don't see the compile time vs. runtime detection as 'competing' approaches, > > > both have their own role. [...] > > > > That's true - but only as long as 'this can be solved in tooling!' is not used as > > an excuse to oppose the runtime solution and we end up doing neither. > > actually, i already voiced my opinion elsewhere in the constify thread on the > kernel hardening list that adding/using __read_only is somewhat premature > without also adding the compile time verification part (as part of the constify > plugin for example). right now its use on the embedded vdso image is simple and > easy to verify but once people begin to add it to variables that the compiler > knows and cares about (say, the ops structures) then things can become fragile > without compile checking. so yes, i'd also advise to get such tooling in > *before* more __read_only usage is added. I think you are mistaken there: if we add the page fault fixup to make sure we don't crash if a read-only variable is accessed, then we'll have most of the benefits of read-only mappings and no fragility - without having to wait for tooling. 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/