linux-kernel - RE: [PATCH] x86/pat: fix pat_x_mtrr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BYAPR21MB16888940067E4363B1321D85D7FF9@BYAPR21MB1688.namprd21.prod.outlook.com>
Date:   Tue, 10 Jan 2023 15:22:31 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Juergen Gross <jgross@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
CC:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: RE: [PATCH] x86/pat: fix pat_x_mtrr_type() for MTRR disabled case

From: Juergen Gross <jgross@...e.com> Sent: Monday, January 9, 2023 10:54 PM
> 
> Since commit 72cbc8f04fe2 ("x86/PAT: Have pat_enabled() properly
> reflect state when running on Xen") PAT can be enabled without MTRR.
> 
> This has resulted in problems e.g. for a SEV-SNP guest running under
> Hyper-V, when trying to establish a new mapping via memremap() with
> WB caching mode, as pat_x_mtrr_type() will call mtrr_type_lookup(),
> which in turn is returning MTRR_TYPE_INVALID due to MTRR being
> disabled in this configuration. The result is a mapping with UC-
> caching, leading to severe performance degradation.
> 
> Fix that by handling MTRR_TYPE_INVALID the same way as MTRR_TYPE_WRBACK
> in pat_x_mtrr_type().
> 
> Fixes: 72cbc8f04fe2 ("x86/PAT: Have pat_enabled() properly reflect state when running on Xen")
> Reported-by: Michael Kelley (LINUX) <mikelley@...rosoft.com>
> Signed-off-by: Juergen Gross <jgross@...e.com>
> ---
>  arch/x86/mm/pat/memtype.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> index 46de9cf5c91d..fb4b1b5e0dea 100644
> --- a/arch/x86/mm/pat/memtype.c
> +++ b/arch/x86/mm/pat/memtype.c
> @@ -387,7 +387,8 @@ static unsigned long pat_x_mtrr_type(u64 start, u64 end,
>  		u8 mtrr_type, uniform;
> 
>  		mtrr_type = mtrr_type_lookup(start, end, &uniform);
> -		if (mtrr_type != MTRR_TYPE_WRBACK)
> +		if (mtrr_type != MTRR_TYPE_WRBACK &&
> +		    mtrr_type != MTRR_TYPE_INVALID)
>  			return _PAGE_CACHE_MODE_UC_MINUS;
> 
>  		return _PAGE_CACHE_MODE_WB;
> --
> 2.35.3

This looks good to me.  I've tested my specific use case of a SEV-SNP guest
running under Hyper-V, where the MTRRs are not visible in the guest but the
PAT is functional.  Previously, this use case showed many "uncached-minus"
entries in /sys/kernel/debug/x86/pat_memtype_list even though the mapping
requests were made as WB.  With this patch, those entries show "write-back",
as expected.

Thanks!

Reviewed-by: Michael Kelley <mikelley@...rosoft.com>
Tested-by: Michael Kelley <mikelley@...rosoft.com>