Received: by 10.223.185.116 with SMTP id b49csp2372124wrg; Thu, 22 Feb 2018 12:38:42 -0800 (PST) X-Google-Smtp-Source: AH8x226OzFH4Fs07/TjPA82hZrhpS8c1h/Emuov357RZbTtrGJB1WWFumNS5fdXsvNSBz/JKccfR X-Received: by 2002:a17:902:d205:: with SMTP id t5-v6mr7988306ply.322.1519331922164; Thu, 22 Feb 2018 12:38:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519331922; cv=none; d=google.com; s=arc-20160816; b=1LOp6QoLCf1bS+9GDyBn2kVdKAogheB7ZTgGrZe1o4Rgn+jsF92rTW0qTzjiCXkrRO EzTuj1LiMkfGGBN0c07SXpUHv0Vk7cW3L/BAjpimeOjfMH4MMbLjioyrXY4jlcZ3M4Xy vyuhJKR8sNBiVfer+YAb3qFUloWcZoWdHFimxswZcY6zB6AaS2DLx7pqSynOPgA4LdW9 ei1TSxUXafkdtKTGbMvPVm16t/sbYGmHe9W9Dgonf3ybF3OnfkY1S6emutb3m8DK9byS 3HdBLditlo/SPSyjWo3kvbwL+eRucXYJmrqCsNJ3Sj603hwGT+ZtTVkUrMrk6OU9MV1T 1zFQ== 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=vVn6rNv3E8UmCal+mfwG5dnt5/0evtbGihhBHxi0YQQ=; b=wGUXV50czeUMl5koG2lnA5ESghkNlYevelNSebtIE+NRpZ21GMF/E5SuoG2xUVVUkX AOQTIgZRwI+Y0thuf/tHQw767sZ44zfxQmlVYBQkSO+YlOaS5hTEES9lB+i/BoJf970g DRG2UWygGZLG4krOoVbotsHhH6JyPK2UVzE06/3cbd4ctJP8qPvE327D2xWTnuG8+9i1 hMauGnODqccLBPiTMz2qa60N4vq8heOAmB80DDwjJjPkGbyNYaEVc3QVpTciUes7fp7E ZwFLJewp2XuPLj73mYYQxly6jtmQI8zyo/lLxYCM+nz5XZqJZMGk5Cizku2acbRjjy+p Eidw== 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 g16-v6si555478plo.369.2018.02.22.12.38.27; Thu, 22 Feb 2018 12:38:42 -0800 (PST) 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 S1751508AbeBVUhT (ORCPT + 99 others); Thu, 22 Feb 2018 15:37:19 -0500 Received: from mga11.intel.com ([192.55.52.93]:61615 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751464AbeBVUhP (ORCPT ); Thu, 22 Feb 2018 15:37:15 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 12:37:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,378,1515484800"; d="scan'208";a="29953242" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by orsmga003.jf.intel.com with ESMTP; 22 Feb 2018 12:37:12 -0800 Subject: [RFC][PATCH 08/10] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init To: linux-kernel@vger.kernel.org Cc: Dave Hansen , aarcange@redhat.com, luto@kernel.org, torvalds@linux-foundation.org, keescook@google.com, hughd@google.com, jgross@suse.com, x86@kernel.org, namit@vmware.com From: Dave Hansen Date: Thu, 22 Feb 2018 12:37:04 -0800 References: <20180222203651.B776810C@viggo.jf.intel.com> In-Reply-To: <20180222203651.B776810C@viggo.jf.intel.com> Message-Id: <20180222203704.62AB5499@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 Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Kees Cook 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-02-22 12:36:21.531036546 -0800 +++ b/arch/x86/mm/pageattr.c 2018-02-22 12:36:21.535036546 -0800 @@ -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; _