From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Date: Sun, 29 Nov 2015 16:39:18 +0100 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 Return-path: 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 Content-Disposition: inline In-Reply-To: <565ADE35.20892.225C67C2@pageexec.freemail.hu> Sender: linux-arch-owner@vger.kernel.org List-ID: 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 * 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