linux-kernel - [PATCH] x86/cpu/AMD: Adjust x86_phys_bits to account for reduced PA in SEV-* guests

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-next>] [day] [month] [year] [list]

Message-Id: <20210317183243.2904919-1-seanjc@google.com>
Date:   Wed, 17 Mar 2021 11:32:43 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org
Cc:     "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        Joerg Roedel <joro@...tes.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Peter Gonda <pgonda@...gle.com>,
        Sean Christopherson <seanjc@...gle.com>
Subject: [PATCH] x86/cpu/AMD: Adjust x86_phys_bits to account for reduced PA
 in SEV-* guests

Always reduce x86_phys_bits per CPUID.0x8000001f[11:6] for SEV-* guests;
the existing flow that queries X86_FEATURE_SEV may or may not trigger
depending on what the VMM emulates, e.g. the VMM likely does not emulate
MSR_K8_SYSCFG.

Print a somewhat scary message and override x86_phys_bits if the VMM
doesn't omit the C-bit from MAXPHYADDR, which can be done either by
enumerating a lower MAXPHYADDR or by enumerating a non-zero
PhysAddrReduction.

Failure to adjust x86_phys_bits results in a false positive for
phys_addr_valid() if the address sets the C-bit, and may also result in
false positives for virt_addr_valid().  This is likely benign for a well-
functioning kernel+drivers, but it's nearly impossible to confidently
audit all users of the *_addr_valid() helpers, so who knows.

Opportunistically force clearing of SME, SEV, and SEV_ES in this case,
as the kernel and KVM treat those feature flags as host capabilities, not
guest capabilities.  This is likely a nop for most deployments, e.g. KVM
doesn't emulate MSR_K8_SYSCFG.

Note, early kernel boot code for SEV-*, e.g. get_sev_encryption_bit(),
_requires_ the SEV feature flag to be set in CPUID in order to identify
SEV (this requirement comes from the SEV-ES GHCB standard).  But, that
requirement does not mean the kernel must also "advertise" SEV in its own
CPU features array.

Fixes: d8aa7eea78a1 ("x86/mm: Add Secure Encrypted Virtualization (SEV) support")
Cc: stable@...r.kernel.org
Cc: Joerg Roedel <joro@...tes.org>
Cc: Tom Lendacky <thomas.lendacky@....com>
Cc: Brijesh Singh <brijesh.singh@....com>
Cc: Peter Gonda <pgonda@...gle.com>
Signed-off-by: Sean Christopherson <seanjc@...gle.com>
---

Regarding clearing SME, SEV, SEV_ES, etc..., it's obviously not required,
but to avoid false postives, identifying "SEV guest" within the kernel
must be done with sev_active().  And if we want to display support in
/proc/cpuinfo, IMO it should be a separate synthetic feature so that
userspace sees "sev_guest" instead of "sev".

 arch/x86/kernel/cpu/amd.c | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 2d11384dc9ab..0f7f8c905226 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -15,6 +15,7 @@
 #include <asm/cpu.h>
 #include <asm/spec-ctrl.h>
 #include <asm/smp.h>
+#include <asm/mem_encrypt.h>
 #include <asm/numa.h>
 #include <asm/pci-direct.h>
 #include <asm/delay.h>
@@ -575,10 +576,33 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
 	resctrl_cpu_detect(c);
 }

+#define SEV_CBIT_MSG "SEV: C-bit (bit %d), overlaps MAXPHYADDR (%d bits).  VMM is buggy or malicious, overriding MAXPHYADDR to %d.\n"
+
 static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
 {
 	u64 msr;

+	/*
+	 * When running as an SEV guest of any flavor, update the physical
+	 * address width to account for the C-bit and clear all of the SME/SVE
+	 * feature flags.  As far as the kernel is concerned, the SEV flags
+	 * enumerate what features can be used by the kernel/KVM, not what
+	 * features have been activated by the VMM.
+	 */
+	if (sev_active()) {
+		int c_bit = ilog2(sme_me_mask);
+
+		BUG_ON(!sme_me_mask);
+
+		c->x86_phys_bits -= (cpuid_ebx(0x8000001f) >> 6) & 0x3f;
+
+		if (c_bit < c->x86_phys_bits) {
+			pr_crit_once(SEV_CBIT_MSG, c_bit, c->x86_phys_bits, c_bit);
+			c->x86_phys_bits = c_bit;
+		}
+		goto clear_all;
+	}
+
 	/*
 	 * BIOS support is required for SME and SEV.
 	 *   For SME: If BIOS has enabled SME then adjust x86_phys_bits by
@@ -612,13 +636,13 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
 			goto clear_sev;

 		return;
+	}

 clear_all:
-		setup_clear_cpu_cap(X86_FEATURE_SME);
+	setup_clear_cpu_cap(X86_FEATURE_SME);
 clear_sev:
-		setup_clear_cpu_cap(X86_FEATURE_SEV);
-		setup_clear_cpu_cap(X86_FEATURE_SEV_ES);
-	}
+	setup_clear_cpu_cap(X86_FEATURE_SEV);
+	setup_clear_cpu_cap(X86_FEATURE_SEV_ES);
 }

 static void early_init_amd(struct cpuinfo_x86 *c)
-- 
2.31.0.rc2.261.g7f71774620-goog