Received: by 10.213.65.68 with SMTP id h4csp579877imn; Fri, 23 Mar 2018 10:49:46 -0700 (PDT) X-Google-Smtp-Source: AG47ELtQrukzKlkGuON6/V2f1NvffPMjdnmGQuv2XIgh7CmJGM9Sv5rs2OYBGCc9AcJAfFxu6X2o X-Received: by 10.98.245.7 with SMTP id n7mr7694865pfh.164.1521827386426; Fri, 23 Mar 2018 10:49:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521827386; cv=none; d=google.com; s=arc-20160816; b=jzkOeZdYpzec2cQxHv7LxxvSHafzP2jxaPKIUUqR/CDz6wW8UdnF459x2+nYa5XMQ8 EWsIOag8Qw2Fib9oBb/axxgYdg9Ht8vHVh8tImCOmfiw26StDpoM3xEwU/9uE5xXrQxT sbzTVSIjHsPTaItzLzh/VA5/E5Kiu7hby6GY1SNZi6J5pLP2PBOu3vrjlCU56/P9G7Fo hJpmUWEHFkSC9JIAl6Zen1ldmPZZOJcgqdFHZFSf7Q+3ykEtVLKMV2TFyX91HZZK6KVh fB5BJR539huK568A6cDIBNPR9VPtJcMiW+gQH3Xavd+mBu4jTnjCzDG4J1BakSRu0gsO A+kw== 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=cYd2a0rDEYYRNVXd/2P2y72x3+44HmmldOhlxCOo8Aw=; b=nKOevq5rcPRJpLcaQRjLccMF55PbSvUnBa0pTwZ3bvlr/9V90yeAFXPzjuB8WD4pAq fR/zmfI8xVcDXtdpRnHaC32cv42IUmxFfezDerR2Sx+bInQtNdY3UN/NbBFH84YqUQLZ y5rYscNLd+cSLWaoafexVQB5p44YM+KQniKXY1sXHmnu7mwbvF81iDHg8ltMQeZV5iQf yM4CcwLB17ltNlbunIqlap9Nx8xv3JHpctntfsuz0hRA7bT/gmmTrf/ZemTMlXi9dHCn maCm76tMDogd/U5pbUb8VBc/VbM4XoNSWMuaNPzdWwiMa6rOrjcTojW5lTStc1KQ7hg1 sfYw== 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 v13si6480388pgq.478.2018.03.23.10.49.31; Fri, 23 Mar 2018 10:49:46 -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 S1752407AbeCWRrF (ORCPT + 99 others); Fri, 23 Mar 2018 13:47:05 -0400 Received: from mga14.intel.com ([192.55.52.115]:6732 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752176AbeCWRrA (ORCPT ); Fri, 23 Mar 2018 13:47:00 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2018 10:47:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,351,1517904000"; d="scan'208";a="40659499" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by fmsmga001.fm.intel.com with ESMTP; 23 Mar 2018 10:47:00 -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, 23 Mar 2018 10:44:59 -0700 References: <20180323174447.55F35636@viggo.jf.intel.com> In-Reply-To: <20180323174447.55F35636@viggo.jf.intel.com> Message-Id: <20180323174459.FC3EBCEF@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-03-21 16:32:00.263192312 -0700 +++ b/arch/x86/mm/pageattr.c 2018-03-21 16:32:00.267192312 -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; _