From nobody Sat Apr 18 21:02:37 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9ECD2C43334 for ; Mon, 11 Jul 2022 10:36:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230328AbiGKKgk (ORCPT ); Mon, 11 Jul 2022 06:36:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229680AbiGKKgR (ORCPT ); Mon, 11 Jul 2022 06:36:17 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D54ADC1BD; Mon, 11 Jul 2022 02:46:40 -0700 (PDT) Date: Mon, 11 Jul 2022 09:46:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1657532798; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZLMKvNlLuZyHt1XbXuDEYOvJvwJl6HGEaIuqT7eYV64=; b=4gandr0iHmpgVnfH1palqXTkSxKGcN12aR4K1CyTNtSGaffyCb+dWp7K8wk0vpTt+xJoyx rXKcRn0N2lUF23d/YUqsCiprvXThwDYU1WGY6lhIBD0A1i9UUSz0oMJ8cvpk25nDgu2kRA zkOVt8z3It5ksiJ/P6cL5wVXKPXJd3zA52DVBlZvXHAuXr38ZXslGvMNSMlxnhSGs5Zu2P wYIM+NA2FhU32A+q5gV/mLWcgsDnjvwra1c9tMRXPQ7GlMk5qrwaXpsQN0U2q/JksD/GY5 BhezqHTLXDaHhPt2+MZUk5UKaDogpbeSzq132OA8d35Jk76uE75Lfz+IW4ZUzQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1657532798; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZLMKvNlLuZyHt1XbXuDEYOvJvwJl6HGEaIuqT7eYV64=; b=RF99lBPVxYAunLo6oCARmlvWP/D0ksFo3M2Af/xw810Muw767HmtHXRvRFeItLgWBYqID3 0iULR2jC/7TQrJDw== From: "tip-bot2 for Juergen Gross" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/urgent] x86/pat: Fix x86_has_pat_wp() Cc: Juergen Gross , Borislav Petkov , , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20220503132207.17234-1-jgross@suse.com> References: <20220503132207.17234-1-jgross@suse.com> MIME-Version: 1.0 Message-ID: <165753279712.15455.2555694789382546026.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/urgent branch of tip: Commit-ID: da4600c76da7d787db04ce059b1f176da8a8d375 Gitweb: https://git.kernel.org/tip/da4600c76da7d787db04ce059b1f176da= 8a8d375 Author: Juergen Gross AuthorDate: Fri, 08 Jul 2022 15:14:56 +02:00 Committer: Borislav Petkov CommitterDate: Mon, 11 Jul 2022 11:37:03 +02:00 x86/pat: Fix x86_has_pat_wp() x86_has_pat_wp() is using a wrong test, as it relies on the normal PAT configuration used by the kernel. In case the PAT MSR has been setup by another entity (e.g. Xen hypervisor) it might return false even if the PAT configuration is allowing WP mappings. This due to the fact that when running as Xen PV guest the PAT MSR is setup by the hypervisor and cannot be changed by the guest. This results in the WP related entry to be at a different position when running as Xen PV guest compared to the bare metal or fully virtualized case. The correct way to test for WP support is: 1. Get the PTE protection bits needed to select WP mode by reading __cachemode2pte_tbl[_PAGE_CACHE_MODE_WP] (depending on the PAT MSR setting this might return protection bits for a stronger mode, e.g. UC-) 2. Translate those bits back into the real cache mode selected by those PTE bits by reading __pte2cachemode_tbl[__pte2cm_idx(prot)] 3. Test for the cache mode to be _PAGE_CACHE_MODE_WP Fixes: f88a68facd9a ("x86/mm: Extend early_memremap() support with addition= al attrs") Signed-off-by: Juergen Gross Signed-off-by: Borislav Petkov Cc: # 4.14 Link: https://lore.kernel.org/r/20220503132207.17234-1-jgross@suse.com --- arch/x86/mm/init.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index d8cfce2..57ba550 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -77,10 +77,20 @@ static uint8_t __pte2cachemode_tbl[8] =3D { [__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] =3D _PAGE_CACHE_MODE_UC, }; =20 -/* Check that the write-protect PAT entry is set for write-protect */ +/* + * Check that the write-protect PAT entry is set for write-protect. + * To do this without making assumptions how PAT has been set up (Xen has + * another layout than the kernel), translate the _PAGE_CACHE_MODE_WP cache + * mode via the __cachemode2pte_tbl[] into protection bits (those protecti= on + * bits will select a cache mode of WP or better), and then translate the + * protection bits back into the cache mode using __pte2cm_idx() and the + * __pte2cachemode_tbl[] array. This will return the really used cache mod= e. + */ bool x86_has_pat_wp(void) { - return __pte2cachemode_tbl[_PAGE_CACHE_MODE_WP] =3D=3D _PAGE_CACHE_MODE_W= P; + uint16_t prot =3D __cachemode2pte_tbl[_PAGE_CACHE_MODE_WP]; + + return __pte2cachemode_tbl[__pte2cm_idx(prot)] =3D=3D _PAGE_CACHE_MODE_WP; } =20 enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)