Received: by 10.213.65.68 with SMTP id h4csp176929imn; Tue, 3 Apr 2018 18:14:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jmF6wTHKHQ656dAYhZ4c2HI0QHBnqV5l3+AhvrBuoPdiIXNYtn0igIZ7x3CeBdgTjEUyG X-Received: by 2002:a17:902:ab98:: with SMTP id f24-v6mr16125237plr.331.1522804454757; Tue, 03 Apr 2018 18:14:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522804454; cv=none; d=google.com; s=arc-20160816; b=0nhS5kUOJT0AgzQew7nhLFcT7gtwNQpDq5q/MEYbwK1ZDOHqTJtCZnSK7vJCD+ikDB rjNdUL7tqwyH8HordP0d0wKJr/PKlOm6eoW52iS+cJ/hkO2oRCCuNc0tmkVW4PcoXIUc ToY/Nh/YMM9H62VONhzMYyZcqu4RGVp+t4nt7zWRR9swweqOq8AuBM3vrp8EI8u432Dm jhZKxY5SPs37uvSJ2xU3nABcIr5PbVPslFwIYYXrwYjpkxSSA+W0jg1060MeyBMSluo8 9DxyShApCJneQibjLn8mCn4LrJAyfSNc85uZLJqHumAyoAmixgeIcxvAaMmS1hNT5gTH OD1A== 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=niKkswS7p8VS9LdtgviDMPpUVikg4E0IxmZNoVITrEE=; b=HEV07R7HWX25ZyhF/elp0tewlOk9YTJOcU/dCxOHvNbgPa7GswJVvNHaVOVVu519XX ueIC13AmZhngL1plUfccmTAtfN63t67/Ha0OKk2MbI8bAZutAisfO5UjMzzbuBvjqPi1 DYiZhcki4yZuNha0V8IM+8QQbsLuTKkdqqGENwy9M6c0mwAKHBZKjKo9eJDeoHyMRkzI 63nr8nKrJiRuPPHanseX2Gw9dUM3NKoynQqbKpYF4eWX4SD+gGdOu4IlBkYCxd4bfdOW ctR6MY7r0EV8xcCtARqSvgsGONwXNqlDtvpGo0+cFQXahlPcRMdsyAJlLDd/AqI+iefW AwKQ== 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 g66si3152014pfa.331.2018.04.03.18.14.00; Tue, 03 Apr 2018 18:14:14 -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 S1755005AbeDDBMy (ORCPT + 99 others); Tue, 3 Apr 2018 21:12:54 -0400 Received: from mga18.intel.com ([134.134.136.126]:20288 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754887AbeDDBMw (ORCPT ); Tue, 3 Apr 2018 21:12:52 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 18:12:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,403,1517904000"; d="scan'208";a="29900881" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by fmsmga008.fm.intel.com with ESMTP; 03 Apr 2018 18:12:51 -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: Tue, 03 Apr 2018 18:10:05 -0700 References: <20180404010946.6186729B@viggo.jf.intel.com> In-Reply-To: <20180404010946.6186729B@viggo.jf.intel.com> Message-Id: <20180404011005.F6B62E51@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-02 16:41:16.620605169 -0700 +++ b/arch/x86/mm/pageattr.c 2018-04-02 16:41:16.624605169 -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; _