Received: by 10.213.65.68 with SMTP id h4csp1067985imn; Fri, 6 Apr 2018 14:02:03 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/1FUmx92DeYduThEK5HNEVC64c4lbS84Xk2jkXudCOzpeOP/9H4re4orl9PaRiRWjcZnMM X-Received: by 2002:a17:902:988d:: with SMTP id s13-v6mr4826885plp.30.1523048523743; Fri, 06 Apr 2018 14:02:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523048523; cv=none; d=google.com; s=arc-20160816; b=0PIkWKFoYj5Vr3QwUYyQwztXZWPbwG7TG5Q5oi/7tFqVOwGs0eaCzf6LC0ClYrPk92 Iz4PeBkpSDdmxTQQDnxQdoObQE0bTGJtDb7A3PGHOtWpempu5YnbpJsEsW4HF/CuEMa7 GUKb5AyQrdzKuXSeFgsXre0uq4DPnbOuMoSSSpbzFrqZA37MlThngoK3cP9I7picA8sp G9161W8RjUtCtGrxJKqio32P9UX9sKT1oZrXwG/wA0/fMzoIvl74q0Sc1+hYX//HZPdE FtBYZ85rHgyrLVEIXSd4VBESA4VBUnVTZBzi7JLhdbOnNCcF7fcq65yBgHabwDLS5HBw s7Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:in-reply-to:references:date :from:cc:to:subject:arc-authentication-results; bh=2lPYiI1z5lpbWH3njE0mOaKwb0F2BCMqL9IeaU5znFQ=; b=z49DnBFyFjRYe6BJqls8uvZ0uman8YvcAlxq4Rj4o0v8kOx+6D7VDXRNfU6vN1nGcU ZuIbUZ9lyXrxvyCxyiJIEDWdCIfv3Qr+2cW5mwwnmAH3CibRrL4LabLkKQR6G2nZacx3 FNoBBuzv1GOsc3S9iAdrJ5AfmOMgB62ndWufEeggjqM1B7Ltvn2Ui4Ol1YWfcWupf/q6 zHbwpdi7tSaZGJrdvnkiYES2wG4/plrIcMyzH7OWEXT2XRlHQwqC0N/g6di+NIPluPTd A0AxgRGkzQYSn3zyP9+lNPPhYmJXkHzYlbX5WsWHqtY9cNkN5MEbGL5Iz6aGv9bFEM0r ohSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v205si7662969pgb.774.2018.04.06.14.01.26; Fri, 06 Apr 2018 14:02:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752282AbeDFU6P (ORCPT + 99 others); Fri, 6 Apr 2018 16:58:15 -0400 Received: from mga05.intel.com ([192.55.52.43]:63503 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752185AbeDFU6L (ORCPT ); Fri, 6 Apr 2018 16:58:11 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 13:58:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,416,1517904000"; d="scan'208";a="214554371" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by orsmga005.jf.intel.com with ESMTP; 06 Apr 2018 13:58:10 -0700 Subject: [PATCH 08/11] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Dave Hansen , keescook@chromium.org, aarcange@redhat.com, luto@kernel.org, torvalds@linux-foundation.org, hughd@google.com, jgross@suse.com, x86@kernel.org, namit@vmware.com From: Dave Hansen Date: Fri, 06 Apr 2018 13:55:14 -0700 References: <20180406205501.24A1A4E7@viggo.jf.intel.com> In-Reply-To: <20180406205501.24A1A4E7@viggo.jf.intel.com> Message-Id: <20180406205514.8D898241@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Hansen __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force the area to be immediately read-only, even if it is early-ish in boot. This caused problems when trying to clear the _PAGE_GLOBAL bit for these area in the PTI code: it cleared _PAGE_GLOBAL like I asked, but also took it up on itself to clear _PAGE_RW. The kernel then oopses the next time it wrote to a __ro_after_init data structure. To fix this, add the kernel_set_to_readonly check, just like we have for kernel text, just a few lines below in this function. Signed-off-by: Dave Hansen Acked-by: Kees Cook Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Hugh Dickins Cc: Juergen Gross Cc: x86@kernel.org Cc: Nadav Amit --- b/arch/x86/mm/pageattr.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff -puN arch/x86/mm/pageattr.c~check-kernel_set_to_readonly arch/x86/mm/pageattr.c --- a/arch/x86/mm/pageattr.c~check-kernel_set_to_readonly 2018-04-06 10:47:57.711796120 -0700 +++ b/arch/x86/mm/pageattr.c 2018-04-06 10:47:57.714796120 -0700 @@ -298,9 +298,11 @@ static inline pgprot_t static_protection /* * The .rodata section needs to be read-only. Using the pfn - * catches all aliases. + * catches all aliases. This also includes __ro_after_init, + * so do not enforce until kernel_set_to_readonly is true. */ - if (within(pfn, __pa_symbol(__start_rodata) >> PAGE_SHIFT, + if (kernel_set_to_readonly && + within(pfn, __pa_symbol(__start_rodata) >> PAGE_SHIFT, __pa_symbol(__end_rodata) >> PAGE_SHIFT)) pgprot_val(forbidden) |= _PAGE_RW; _