From nobody Sat Apr 18 14:13:52 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 02AE8C43334 for ; Wed, 13 Jul 2022 10:45:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235695AbiGMKpQ (ORCPT ); Wed, 13 Jul 2022 06:45:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235223AbiGMKpM (ORCPT ); Wed, 13 Jul 2022 06:45:12 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C63B9F990A; Wed, 13 Jul 2022 03:45:10 -0700 (PDT) Date: Wed, 13 Jul 2022 10:45:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1657709108; 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=1/THw7b/dbCSKOAhofrOGXHOh63A6XAgjMRnWLsvrJA=; b=SWRHQGrFhvX1JSx0tpSAfdznl8nLJM/Pt/acFI3bc7rikKSU/F+ZuCRKdi80iHrrIBYtb2 Xv7x07Ck9C3SDJDOw9pI6n0NixRsuyhj/1Q4OcGNvy2WGRvE9IG/BiL2KR2TNJu5doCFLb sgAL7vj37zTlfO3ouUt7WWNLKVosqWfs4IcDXOrzYftqRZ2wUpkUAHdf6U/88GL6BtrzEO +gXwcgdHB62VCoZbfMjaFCFyS9U5vK7f5EQXMLsxWz+sM7fe67qQipqEcC3AXOQgoM8ajc PcFWA2TeKe2/JhJAoxXN6hDspUNnQgDaOrPY6CrwpGCl44XMt26e5cR07mzHpg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1657709108; 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=1/THw7b/dbCSKOAhofrOGXHOh63A6XAgjMRnWLsvrJA=; b=rT44xZSnfADOpOp06QXPTXhS17NuL63Tm7ajRHypv8VKr+jXQR6qTZnDnW/bRrSY5po16y wuWaIqr+umZBkDDQ== 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: <165770910660.15455.10226651626540518739.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: f0592491eba2e42cc84d7831750b84cfc0150dde Gitweb: https://git.kernel.org/tip/f0592491eba2e42cc84d7831750b84cfc= 0150dde Author: Juergen Gross AuthorDate: Fri, 08 Jul 2022 15:14:56 +02:00 Committer: Borislav Petkov CommitterDate: Wed, 13 Jul 2022 12:21: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)