Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp6824889ybx; Mon, 11 Nov 2019 15:35:41 -0800 (PST) X-Google-Smtp-Source: APXvYqz+3Iu1eexiAbhEadfV386kQr5aFBqEtKeLYcKz32d2jvvGRK50eOXOonj1urSN6fhzFfRC X-Received: by 2002:a05:6402:602:: with SMTP id n2mr30157832edv.23.1573515341282; Mon, 11 Nov 2019 15:35:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573515341; cv=none; d=google.com; s=arc-20160816; b=s9r+ZlChzSipZkQqlZ4U3FqqwEDHWvHzWfe0fzPMjM2+h5nFsAZX0yo2T/VCZpowPM /vhCzkTd0L+RGNkl0C+jj4q8CMQZ+S9KtqYeAj7GechYnBnVmRcREc6vSQSUh8ixVbPg aLaHp68Bz2P4Vd5UyMh5FMEdpd/3Uj29rneYef76pz6BR4cbHof/REzUv/1Qw2V8nNwm xDHi+/2pUMVzWIBj2ukHkt4jEUt5qcu/3fqGNc4sW81vtgNyCusOEPeiMWN84gCPcVuL dk0awf6QBNt2pizQPFN3hK5CMWgVXVBq3vEnf0cgmae8hGqBzj/4gzOwmwylSyHxXHyC /fTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=yw8FaSDxdA+brD0InYb9NkuQLMAEyFBqq1WpNTucq/g=; b=LzvPd3eSv4+oLpcqwymkyB1qIvA6s1ijdhAB+Ziqo+Zj41BlspB1UOigp07kguXUYL EhegnaGvpb4qPHihQhU0fLL6tDWSyMbCghAfcdTW7ZjoRDmXZ7iTpAu1nQmwTSPsjMIq ELGRExTQHMKtEG5lPxflCI6o9VylRkJglrnmB2FUAD/K1vtnCAjnojIOlsPjdvot2tMi stneSlTO71SzLoPREPKbPbc4oX/zGQIDCv+pj+uM5Y91uhaHuxDLqx29wvyIGNy0bnnf xS4bU/auRpZYo372+L4VUs4xcstCymW9A/o5o+RGmXD8yP8Flf1eavsijgy2fT79pyKO JW/g== 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 a27si12692220edm.187.2019.11.11.15.35.17; Mon, 11 Nov 2019 15:35:41 -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 S1727336AbfKKXcg (ORCPT + 99 others); Mon, 11 Nov 2019 18:32:36 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:60238 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726877AbfKKXcg (ORCPT ); Mon, 11 Nov 2019 18:32:36 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iUJAK-0001cf-3j; Tue, 12 Nov 2019 00:32:13 +0100 Date: Tue, 12 Nov 2019 00:32:11 +0100 (CET) From: Thomas Gleixner To: zhong jiang cc: dave.hansen@linux.intel.com, peterz@infradead.org, mingo@redhat.com, luto@kernel.org, bp@alien8.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] x86/mm: Mask out unsupported bit when it set noexec=off In-Reply-To: <1573465994-33249-1-git-send-email-zhongjiang@huawei.com> Message-ID: References: <1573465994-33249-1-git-send-email-zhongjiang@huawei.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Zhong, On Mon, 11 Nov 2019, zhong jiang wrote: > Commit 510bb96fe5b3 ("x86/mm: Prevent bogus warnings with "noexec=off"") > use __supported_pte_mask to replace __default_kernel_pte_mask to mask > out the unsupported bits. It works when the command line set noexec=off. > > It also seems to works to use __supported_pte_mask instead in native_set_fixmap. "Seems to work" is really not a good engineering principle and neither a good rationale WHY this change is correct, which it is not. > @@ -647,7 +647,7 @@ void native_set_fixmap(unsigned /* enum fixed_addresses */ idx, > phys_addr_t phys, pgprot_t flags) > { > /* Sanitize 'prot' against any unsupported bits: */ > - pgprot_val(flags) &= __default_kernel_pte_mask; > + pgprot_val(flags) &= __supported_pte_mask; > > __native_set_fixmap(idx, pfn_pte(phys >> PAGE_SHIFT, flags)); > } The commit you mentioned switched __early_set_fixmap() to __supported_pte_mask because __default_kernel_pte_mask is not yet set up at that point which caused the following warning: attempted to set unsupported pgprot: 8000000000000163 bits: 8000000000000000 supported: 7fffffffffffffff At this point __default_kernel_pte_mask is still compile time initialized to ~0UL, i.e. all bits set which allows the NX bit to be set, but it's not supported according to __supported_pte_mask. Once __default_kernel_pte_mask is properly runtime initialized to: __default_kernel_pte_mask = __supported_pte_mask; in probe_page_size_mask() there is no reason that subsequent code uses __supported_pte_mask. In fact that's just wrong because __default_kernel_pte_mask can have extra bits cleared during runtime initialization, e.g.: /* Except when with PTI where the kernel is mostly non-Global: */ if (cpu_feature_enabled(X86_FEATURE_PTI)) __default_kernel_pte_mask &= ~_PAGE_GLOBAL; So your change "works", but subtly breaks PTI protections. Please be more careful next time and really analyse why your change is correct and provide this analysis in the changelog. Thanks, tglx