linux-kernel - Re: [PATCH v5 04/15] x86/mtrr: support setting MTRR state for software defined MTRRs

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: <20230411132040.GHZDVeqCqATbbgzdXK@fat_crate.local>
Date:   Tue, 11 Apr 2023 15:20:40 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Juergen Gross <jgross@...e.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Michael Kelley <mikelley@...rosoft.com>
Subject: Re: [PATCH v5 04/15] x86/mtrr: support setting MTRR state for
 software defined MTRRs

On Sat, Apr 01, 2023 at 08:36:41AM +0200, Juergen Gross wrote:
> When running virtualized, MTRR access can be reduced (e.g. in Xen PV
> guests or when running as a SEV-SNP guest under Hyper-V). Typically
> the hypervisor will reset the MTRR feature in CPUID data, resulting
> in no MTRR memory type information being available for the kernel.
> 
> This has turned out to result in problems:

Let's add the links to those problems:

> - Hyper-V SEV-SNP guests using uncached mappings where they shouldn't

I can't find Michael's original report, do you have a link?

> - Xen PV dom0 mapping memory as WB which should be UC- instead

Link: https://lore.kernel.org/all/4fe9541e-4d4c-2b2a-f8c8-2d34a7284930@nerdbynature.de/

> 
> Solve those problems by supporting to set a static MTRR state,

s/by supporting to set a/allowing an MTRR static state override/

> +void mtrr_overwrite_state(struct mtrr_var_range *var, unsigned int num_var,
> +			  mtrr_type def_type)
> +{
> +	unsigned int i;
> +
> +	/* Only allowed to be called once before mtrr_bp_init(). */
> +	if (WARN_ON(mtrr_state_set))

WARN_ON_ONCE() is probably better.

> +		return;
> +
> +	/* Only allowed when running virtualized. */
> +	if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
> +		return;
> +
> +	/*
> +	 * Only allowed for special virtualization cases:
> +	 * - when running as SEV-SNP guest
> +	 * - when running as Hyper-V isolated guest

	when running as a SEV-SNP guest on a HyperV with vTOM enabled

that's a single condition.

> +	 * - when running as Xen PV guest
> +	 * - when running as TSX guest
> +	 */
> +	if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP) &&
> +	    !hv_is_isolation_supported() &&
> +	    !cpu_feature_enabled(X86_FEATURE_XENPV) &&
> +	    !cpu_feature_enabled(X86_FEATURE_TDX_GUEST))

IOW:

	if (!(hv_is_isolation_supported() && cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) &&
	    !cpu_feature_enabled(X86_FEATURE_XENPV) &&
	    !cpu_feature_enabled(X86_FEATURE_TDX_GUEST))


-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette