Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753296AbbKYLGR (ORCPT ); Wed, 25 Nov 2015 06:06:17 -0500 Received: from r00tworld.com ([212.85.137.150]:39199 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752511AbbKYLGN (ORCPT ); Wed, 25 Nov 2015 06:06:13 -0500 From: "PaX Team" To: kernel-hardening@lists.openwall.com, Mathias Krause Date: Wed, 25 Nov 2015 12:05:25 +0100 MIME-Version: 1.0 Subject: Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Reply-to: pageexec@freemail.hu CC: "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: <565595F5.32536.DB9FE75@pageexec.freemail.hu> In-reply-to: References: <1448401114-24650-1-git-send-email-keescook@chromium.org>, 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]); Wed, 25 Nov 2015 12:05:19 +0100 (CET) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1616 Lines: 33 On 25 Nov 2015 at 10:13, Mathias Krause wrote: > I myself had some educating experience seeing my machine triple fault > when resuming from a S3 sleep. The root cause was a variable that was > annotated __read_only but that was (unnecessarily) modified during CPU > bring-up phase. Debugging that kind of problems is sort of a PITA, you > could imagine. actually the kernel could silently recover from this given how the page fault handler could easily determine that the fault address fell into the data..read_only section and just silently undo the read-only property, log the event to dmesg and retry the faulting access. > So, prior extending the usage of the __read_only annotation some > toolchain support is needed. Maybe a gcc plugin that'll warn/error on > code that writes to such a variable but is not __init itself. this is exactly what i suggested earlier in the constify thread ;). note that this will produce false positives because __init* annotations are not propagated everywhere they could be. > The initify and checker plugins from the PaX patch might be worth to > look at for that purpose, as they're doing similar things already. one of our plans for initify is to add the discovery and propagation of _init* annotations as well, it'd not only fix the false positives mentioned above but also help reduce the kernel size (code/data/rodata). -- 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/