Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp382808pxb; Thu, 21 Oct 2021 01:11:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzD551JkDRYn0lmz8m3yfGE5DrxJ1gntr+I1f9kWzK7wigjm4ylrRCR6jK10r7nYQKezG9J X-Received: by 2002:a62:5804:0:b0:44b:b75b:ec8f with SMTP id m4-20020a625804000000b0044bb75bec8fmr4084705pfb.63.1634803869240; Thu, 21 Oct 2021 01:11:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634803869; cv=none; d=google.com; s=arc-20160816; b=DhMI/5OsO0N/zmEAaTxOuyL3gUDioZhnquGH8bEX22XKB4RtPOQ0fDRNLOm3hflFBW W5TyjXmy4DvyOBJ1ISOkrYdV9P18q/NCCTN8sX8JLHRCs+bTPZXKE8efL2sAFjkoRPHi wsVHUMoZcNJdzfPkmgM891ABEWPaWXn+i+0CBJ9PId2XB6ON3eNnP1mr10zh7kzqU9hy 23tITZhHRag1i2aRVOZ+6zRhYQbzevAcUhURI9GHRCaLwiQpGmGWD7iHOMuGbCeYuZeR 9Bn6ENqGAejPoBbI3GRbY5nGBbNs7MVz+4+ckMa5tAeOEIxE3fKQvQoIzbt0WBjhK58g bFTQ== 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=upYmnzkMDACOHviYODB85IimgGgrmeADbB4AtQakN80=; b=PsIr2RpZvm3Zr5AfWYWtNpH+2q2lCP2TRxgGp3MklIRR+7XIbXHjnaKhS9rYHujRuU S7wsW+iOLTGZDyLyBFzpRHGMoMmmu7WvRPrC4iHWIQQKYOu9L98VQFMlRO2tZub0uq2f 8ES9Y1JyxNWwYrdIOUsGReos3qNYFuJ8WuROAkOGbfhmNrypILycxrnD1Ml6ndG7D6Zd EJN9psk2/14e/5mjwgKRv1n2KhRXoYU2imvCY+VTzXucUh3VQP1qLsX9AJ2jtgwtDbOX MC4TVpvl+2GUP99TRL3CsIr1ESpJcC/qYFJfctfYNmOUsG48bFhL9Kbtf62R0p8ie4Oz 55pQ== 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 q91si5981794pja.33.2021.10.21.01.10.49; Thu, 21 Oct 2021 01:11:09 -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 S231488AbhJUILE (ORCPT + 99 others); Thu, 21 Oct 2021 04:11:04 -0400 Received: from 8bytes.org ([81.169.241.247]:34400 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231474AbhJUIK6 (ORCPT ); Thu, 21 Oct 2021 04:10:58 -0400 Received: from cap.home.8bytes.org (p4ff2b5b0.dip0.t-ipconnect.de [79.242.181.176]) (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 6768E29C; Thu, 21 Oct 2021 10:08:38 +0200 (CEST) From: Joerg Roedel To: x86@kernel.org Cc: Joerg Roedel , Joerg Roedel , Xinyang Ge , hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , David Rientjes , Marc Orr , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Sean Christopherson , Martin Radev , Arvind Sankar , linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: [PATCH 2/2] x86/sev: Allow #VC exceptions on the VC2 stack Date: Thu, 21 Oct 2021 10:08:33 +0200 Message-Id: <20211021080833.30875-3-joro@8bytes.org> X-Mailer: git-send-email 2.33.1 In-Reply-To: <20211021080833.30875-1-joro@8bytes.org> References: <20211021080833.30875-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 When code running on the VC2 stack causes a nested VC exception, the handler will not handle it as expected but goes again into the error path. The result is that the panic() call happening when the VC exception was raised in an invalid context is called recursively. Fix this by checking the interrupted stack too and only call panic if it is not the VC2 stack. Reported-by: Xinyang Ge Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") Signed-off-by: Joerg Roedel --- arch/x86/kernel/sev.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c index a6895e440bc3..f39165b5fa34 100644 --- a/arch/x86/kernel/sev.c +++ b/arch/x86/kernel/sev.c @@ -1319,13 +1319,26 @@ static __always_inline void vc_forward_exception(struct es_em_ctxt *ctxt) } } -static __always_inline bool on_vc_fallback_stack(struct pt_regs *regs) +static __always_inline bool is_vc2_stack(unsigned long sp) { - unsigned long sp = (unsigned long)regs; - return (sp >= __this_cpu_ist_bottom_va(VC2) && sp < __this_cpu_ist_top_va(VC2)); } +static __always_inline bool vc_from_invalid_context(struct pt_regs *regs) +{ + unsigned long sp, prev_sp; + + sp = (unsigned long)regs; + prev_sp = regs->sp; + + /* + * If the code was already executing on the VC2 stack when the #VC + * happened, let it proceed to the normal handling routine. This way the + * code executing on the VC2 stack can cause get #VC exceptions handled. + */ + return is_vc2_stack(sp) && !is_vc2_stack(prev_sp); +} + static bool vc_raw_handle_exception(struct pt_regs *regs, unsigned long error_code) { struct ghcb_state state; @@ -1406,7 +1419,7 @@ DEFINE_IDTENTRY_VC_KERNEL(exc_vmm_communication) * But keep this here in case the noinstr annotations are violated due * to bug elsewhere. */ - if (unlikely(on_vc_fallback_stack(regs))) { + if (unlikely(vc_from_invalid_context(regs))) { instrumentation_begin(); panic("Can't handle #VC exception from unsupported context\n"); instrumentation_end(); -- 2.33.1