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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dc553a8a-d71b-9a55-be16-fca16ec92f01@netscape.net>
Date:   Fri, 2 Sep 2022 14:16:25 -0400
From:   Chuck Zmudzinski <brchuckz@...scape.net>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Beulich <jbeulich@...e.com>, Borislav Petkov <bp@...e.de>,
        Juergen Gross <jgross@...e.com>,
        Thorsten Leemhuis <regressions@...mhuis.info>
Cc:     stable@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Lucas De Marchi <lucas.demarchi@...el.com>,
        regressions@...ts.linux.dev, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5.19 109/158] x86/PAT: Have pat_enabled() properly reflect
 state when running on Xen

On 8/29/2022 6:59 AM, Greg Kroah-Hartman wrote:
> From: Jan Beulich <jbeulich@...e.com>
>
> commit 72cbc8f04fe2fa93443c0fcccb7ad91dfea3d9ce upstream.
>
> After commit ID in the Fixes: tag, pat_enabled() returns false (because
> of PAT initialization being suppressed in the absence of MTRRs being
> announced to be available).
>
> This has become a problem: the i915 driver now fails to initialize when
> running PV on Xen (i915_gem_object_pin_map() is where I located the
> induced failure), and its error handling is flaky enough to (at least
> sometimes) result in a hung system.
>
> Yet even beyond that problem the keying of the use of WC mappings to
> pat_enabled() (see arch_can_pci_mmap_wc()) means that in particular
> graphics frame buffer accesses would have been quite a bit less optimal
> than possible.
>
> Arrange for the function to return true in such environments, without
> undermining the rest of PAT MSR management logic considering PAT to be
> disabled: specifically, no writes to the PAT MSR should occur.
>
> For the new boolean to live in .init.data, init_cache_modes() also needs
> moving to .init.text (where it could/should have lived already before).
>
>   [ bp: This is the "small fix" variant for stable. It'll get replaced
>     with a proper PAT and MTRR detection split upstream but that is too
>     involved for a stable backport.
>     - additional touchups to commit msg. Use cpu_feature_enabled(). ]
>
> Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")
> Signed-off-by: Jan Beulich <jbeulich@...e.com>
> Signed-off-by: Borislav Petkov <bp@...e.de>
> Acked-by: Ingo Molnar <mingo@...nel.org>
> Cc: <stable@...r.kernel.org>
> Cc: Juergen Gross <jgross@...e.com>
> Cc: Lucas De Marchi <lucas.demarchi@...el.com>
> Link: https://lore.kernel.org/r/9385fa60-fa5d-f559-a137-6608408f88b0@suse.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> ---
>  arch/x86/mm/pat/memtype.c |   10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> --- a/arch/x86/mm/pat/memtype.c
> +++ b/arch/x86/mm/pat/memtype.c
> @@ -62,6 +62,7 @@
>  
>  static bool __read_mostly pat_bp_initialized;
>  static bool __read_mostly pat_disabled = !IS_ENABLED(CONFIG_X86_PAT);
> +static bool __initdata pat_force_disabled = !IS_ENABLED(CONFIG_X86_PAT);
>  static bool __read_mostly pat_bp_enabled;
>  static bool __read_mostly pat_cm_initialized;
>  
> @@ -86,6 +87,7 @@ void pat_disable(const char *msg_reason)
>  static int __init nopat(char *str)
>  {
>  	pat_disable("PAT support disabled via boot option.");
> +	pat_force_disabled = true;
>  	return 0;
>  }
>  early_param("nopat", nopat);
> @@ -272,7 +274,7 @@ static void pat_ap_init(u64 pat)
>  	wrmsrl(MSR_IA32_CR_PAT, pat);
>  }
>  
> -void init_cache_modes(void)
> +void __init init_cache_modes(void)
>  {
>  	u64 pat = 0;
>  
> @@ -313,6 +315,12 @@ void init_cache_modes(void)
>  		 */
>  		pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
>  		      PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
> +	} else if (!pat_force_disabled && cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) {
> +		/*
> +		 * Clearly PAT is enabled underneath. Allow pat_enabled() to
> +		 * reflect this.
> +		 */
> +		pat_bp_enabled = true;
>  	}
>  
>  	__init_cache_modes(pat);
>
>

Dear Boris, Jan, Juergen, Thorsten, and Greg,

Just a note to say thanks to everyone who worked on this regression.
I just upgraded my Xen PV dom0 on fc36 that was affected with the
Fedora build of 5.19.6, which has the fix, and it works fine.

Thanks again,

Chuck

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ