Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4476246pxu; Tue, 20 Oct 2020 19:22:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgVX6e13i5CVDHx7+3mg2cTItWHWCo2mObXKMSZVYK4RjIBisOWxq9kDcrX+gadu62tdi4 X-Received: by 2002:a50:9a86:: with SMTP id p6mr836635edb.96.1603246921394; Tue, 20 Oct 2020 19:22:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603246921; cv=none; d=google.com; s=arc-20160816; b=uWOj/2WtJwwjWFHxGLHAOpoomGdHeerTdsk2Okgo1EA/P1P4PgCHSDSkhq1/1AQ+78 dazz+L4G0x4RiQzauTISUOxXIM6JGLsb2cWgQYBFXSN0K5LPRAXMWFSZhNFTmJR8sa4x wMUkEcBvvtkVqG+DGlotvwNf/PKSkUU2xMV05SBCiLiXcbOFBxSBg5Bl4bDLUUGnJI6I pOmaVrMh+EZl7HfGSEdCTxywAXti5XZRuW5LatF9FrtJfc469RVCBSLWwq4ZxivbGs6+ bpMp4WD2x5MLqDdVb4eQ727Cr5DVcooLE/zzavR41/bfTvV+hw09xTk5Fhn6wb1rB3uC fwMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=ryjCwXFnXnXU3kOtMDkknzIEoeTEdo+nF1ZdQ6iZidE=; b=Ddz5lHZmMZkdtpvt+r1U/eyElS9XLQYttKspG0T1Mi+Sj/xXRGSx+2v7AvOH3SLVxG eNdSpEOed0I3PEusRIWcRKRYY+mpqeLncs0ZQaN7qOUpOgp60sKo4ILW0Bw5GsgxJPfc zpVQ5KZHUWX35o5wyEgpE4uNBYxA2Ho6Wxq58m/JdvPcDJyigYGes+hDltMUKk1fQmPS jkw4FTUpX1cqul/4YLCzx4Yh1POlwT4ziaw9pTnw+WIN0Sbwd6nX4CoS+71wiyAFJ7BZ esjLQJezbTQkSxgdIZUgdibYYixiQ6ByuUz3TGkwOPe+cYXiFducsuZL4EWMaJ0TCOUd O2jg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ck29si428332edb.267.2020.10.20.19.21.38; Tue, 20 Oct 2020 19:22:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394306AbgJTMTJ (ORCPT + 99 others); Tue, 20 Oct 2020 08:19:09 -0400 Received: from 8bytes.org ([81.169.241.247]:34848 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394290AbgJTMTI (ORCPT ); Tue, 20 Oct 2020 08:19:08 -0400 Received: from cap.home.8bytes.org (p549add56.dip0.t-ipconnect.de [84.154.221.86]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by theia.8bytes.org (Postfix) with ESMTPSA id 5D3A8295; Tue, 20 Oct 2020 14:19:06 +0200 (CEST) From: Joerg Roedel To: x86@kernel.org Cc: Joerg Roedel , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Kees Cook , Arvind Sankar , Martin Radev , Tom Lendacky , linux-kernel@vger.kernel.org Subject: [PATCH v2 2/5] x86/boot/compressed/64: Add CPUID sanity check to early #VC handler Date: Tue, 20 Oct 2020 14:18:53 +0200 Message-Id: <20201020121856.19427-3-joro@8bytes.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201020121856.19427-1-joro@8bytes.org> References: <20201020121856.19427-1-joro@8bytes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joerg Roedel The early #VC handler which doesn't have a GHCB can only handle CPUID exit codes. It is needed by the early boot code to handle #VC exceptions raised in verify_cpu() and to get the position of the C bit. But the CPUID information comes from the hypervisor, which is untrusted and might return results which trick the guest into the no-SEV boot path with no C bit set in the page-tables. All data written to memory would then be unencrypted and could leak sensitive data to the hypervisor. Add sanity checks to the early #VC handlers to make sure the hypervisor can not pretend that SEV is disabled. Signed-off-by: Joerg Roedel --- arch/x86/kernel/sev-es-shared.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/arch/x86/kernel/sev-es-shared.c b/arch/x86/kernel/sev-es-shared.c index 5f83ccaab877..48bb14563dcd 100644 --- a/arch/x86/kernel/sev-es-shared.c +++ b/arch/x86/kernel/sev-es-shared.c @@ -178,6 +178,32 @@ void __init do_vc_no_ghcb(struct pt_regs *regs, unsigned long exit_code) goto fail; regs->dx = val >> 32; + /* + * This is a VC handler and it is only raised when SEV-ES is active, + * which means SEV must be active too. Do sanity checks on the CPUID + * results to make sure the hypervisor does not trick the kernel into + * the no-sev path. This could map sensitive data unencrypted and make + * it accessible to the hypervisor. + * + * In particular, check for: + * - Hypervisor CPUID bit + * - Availability of CPUID leaf 0x8000001f + * - SEV CPUID bit. + * + * The hypervisor might still report the wrong C-bit position, but this + * can't be checked here. + */ + + if ((fn == 1 && !(regs->cx & BIT(31)))) + /* Hypervisor Bit */ + goto fail; + else if (fn == 0x80000000 && (regs->ax < 0x8000001f)) + /* SEV Leaf check */ + goto fail; + else if ((fn == 0x8000001f && !(regs->ax & BIT(1)))) + /* SEV Bit */ + goto fail; + /* Skip over the CPUID two-byte opcode */ regs->ip += 2; -- 2.28.0