linux-kernel - RE: [PATCH 0/6] x86/mtrr: fix handling with PAT but without 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <BYAPR21MB16886C389C45912DB4EBA362D7D89@BYAPR21MB1688.namprd21.prod.outlook.com>
Date:   Wed, 8 Feb 2023 15:08:15 +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:     "lists@...dbynature.de" <lists@...dbynature.de>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: RE: [PATCH 0/6] x86/mtrr: fix handling with PAT but without MTRR

From: Juergen Gross <jgross@...e.com> Sent: Monday, February 6, 2023 11:29 PM
> 
> This series tries to fix the rather special case of PAT being available
> without having MTRRs (either due to CONFIG_MTRR being not set, or
> because the feature has been disabled e.g. by a hypervisor).
> 
> The main use cases are Xen PV guests and SEV-SNP guests running under
> Hyper-V.
> 
> Patch 2 seems to be a little hacky, as it special cases only
> memtype_reserve() and memtype_free(), but OTOH this doesn't seem to
> be worse than in previous days, where PAT was disabled when MTRRs
> haven't been available.
> 
> My tests with Xen didn't show any problems, but I'm rather sure I
> couldn't cover all corner cases.

I tested this patch set with Hyper-V SEV-SNP guests, and ioremap_cache()
is correctly mapping as WB.

As an observation, with commit 90b926e68f50 it was nice to have
the memtype entries created.  I could check for any unexpected
mappings in /sys/kernel/debug/x86/pat_memtype_list.  With this patch
set, we're back to not creating those entries.  

Michael

> 
> The only cleaner solution I could think of would be to introduce MTRR
> read-only access. It would theoretically be possible to get the actual
> MTRR contents for the variable MTRRs from Xen, but I'm not sure this
> is really the way to go.
> 
> For the SEV-SNP case with Hyper-V I guess such a read-only mode could
> be rather simple, but I'm really not sure this would cover all needed
> corner cases (I'd basically say always "WB" in that case).
> 
> I have added more cleanup which has been discussed when looking into
> the most recent failures.
> 
> Juergen Gross (6):
>   x86/mtrr: make mtrr_enabled() non-static
>   x86/pat: check for MTRRs enabled in memtype_reserve()
>   x86/mtrr: revert commit 90b926e68f50
>   x86/mtrr: don't let mtrr_type_lookup() return MTRR_TYPE_INVALID
>   x86/mm: only check uniform after calling mtrr_type_lookup()
>   x86/mtrr: drop sanity check in mtrr_type_lookup_fixed()
> 
>  arch/x86/include/asm/mtrr.h        | 13 +++++++++++--
>  arch/x86/include/uapi/asm/mtrr.h   |  6 +++---
>  arch/x86/kernel/cpu/mtrr/generic.c | 10 +++-------
>  arch/x86/kernel/cpu/mtrr/mtrr.c    |  2 +-
>  arch/x86/mm/pat/memtype.c          | 13 ++++++++-----
>  arch/x86/mm/pgtable.c              |  6 ++----
>  6 files changed, 28 insertions(+), 22 deletions(-)
> 
> --
> 2.35.3