Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp761479pxb; Mon, 25 Oct 2021 18:23:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+mVjZmaOrKvqFYd7d/t220deoRsjPBX0S0NY9D9PhH/teHGBVm05Mvrd5XoSHsuIQ658E X-Received: by 2002:a50:e004:: with SMTP id e4mr31779458edl.246.1635211400201; Mon, 25 Oct 2021 18:23:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635211400; cv=none; d=google.com; s=arc-20160816; b=kUBAP0Pm2iHQSbI/LRSUz5xan6oW/VRmvBQBYDSNijSLCxjplPxdGQNOvIErfdsPcf yK07UUw+1KIoeHAyw5W7bCABP3CNi+xxlKMpvIZUCOjgF/0F093nyTioy5pAGOQ7Ift+ xII7tvSsvjtFCz8OQLqoTkOoxC3fs4T6uaEY/aPt3ferWIBizHsZCnmcXy7ekVkR3hg4 wGuotvEwH+5D9Q3qC7r6K2C/BeDmXJpwim2ir9RI4/cc06F6kolhUtjiKC/GjQKgEkmF 9mx1ErGx9wjWmO1VPALltEKFDvq/jeQbZpDF+7vRpdf+to29Z8E4B9MGYHD/uMDPxaVU 04rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=lr8LZgkPwRWJNrzlR7/1JMJvMp3PtBdOlimdKnBnxLk=; b=GvkolH25gtBEy+rZIeaucDMYm71JtGYrJB728ne4MtLqeURVlETU+ltn/GDom0w2Vs /qYjy74oNKmDWJH5T2R+vTtH35454x5pgvY0mQGu9w5tAn+di6PE8IJXpucXbow/Gzbx MpV+9KbrFfG9G3nwAEtdHbPltpvUnUJMge+8zAEcAwplAAxy2Ua4LhzGPGJR+xRyfmmU nfxkqyAjybD2iecbWfsohY1cOhW8U22JFexw1/UeWEFY/lZ/BbDCFwT7XL5MU1igfht1 ICfTs0riuYrJKznVPJnxb0CLKqP2+HQUFWm//WStAPHsydEsLawkG3BA3T4O29XcDD4y fwGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=is4zuvBz; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb14si40020699edb.415.2021.10.25.18.22.56; Mon, 25 Oct 2021 18:23:20 -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; dkim=pass header.i=@google.com header.s=20210112 header.b=is4zuvBz; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234465AbhJYU6f (ORCPT + 99 others); Mon, 25 Oct 2021 16:58:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232690AbhJYU6d (ORCPT ); Mon, 25 Oct 2021 16:58:33 -0400 Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82228C061745 for ; Mon, 25 Oct 2021 13:56:10 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id z5-20020a9d4685000000b005537cbe6e5aso9995177ote.1 for ; Mon, 25 Oct 2021 13:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lr8LZgkPwRWJNrzlR7/1JMJvMp3PtBdOlimdKnBnxLk=; b=is4zuvBzpafyka1/8lyKw28YpFS3Noe7Q2cQ69D4IStId6bDNCGsjDoUK/gfaUVtGk WIlB/GxcYkckRxH4aN4yejJGpfZowglMmqJ0nZeqYysDPIml9ILTGB7SjxP/wOmuOQHz G/rjSagiJJ4AbhrsLit+wQqfDeyNf9EQsJJDbOYvh8R2g5DrApaVyOIl6lhdJ0TXTFyg fnueEiOHifqeWRMoXzC0dRFJeZLbQiZpusr4rWn2zyyjND+N7uFxr3TlsZEC1REr02Y+ nWZJ6yRWm6qcS/6i7Mx3qNz55+9nHlOFU/vrTsstX0CZjCdA1TZClinlF9kBalzzHF1y dclA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lr8LZgkPwRWJNrzlR7/1JMJvMp3PtBdOlimdKnBnxLk=; b=kchyileyYldk1MZWQbGFRTtIhQctbxe1bplKIH6l1hIDMpa5o+LSkEMfvnPetpKaSu 55UDUtuP8DDB8OB/yPLyrwJKgoF18wW6S3E8QUHk1HjPPyeWLpF50tBxdzlptye1E2cz EQzr6KrkUI63AhGrTmJDpqtZpxLjKJGdN0IrNf4xZcztHqQDdPIdpTSfDAoiDkuo3kVg sCIf4uxzeZkyIQiy6RAmEU+q/DH8peyIDv3yhEjLNnptOU+P1cfmNrmJLHeMCv7m5fhg Oud3i04YXZos0ByYPyXyTGL4hcAQ3WcWnyG5dNtkSeLZ/ZZJXBkseSB+MyrAopeCM8sJ UeMA== X-Gm-Message-State: AOAM5333WVzbq/GT4aEwAhDr2n7ZQO75reEQp7x8QveLD+qeCHKuox7b X/BrL/13bO8TFhlWgyavbQtAOfywipzds0gwxGNP2Q== X-Received: by 2002:a05:6830:2492:: with SMTP id u18mr16119610ots.29.1635195369622; Mon, 25 Oct 2021 13:56:09 -0700 (PDT) MIME-Version: 1.0 References: <20211025162517.2152628-1-pbonzini@redhat.com> In-Reply-To: <20211025162517.2152628-1-pbonzini@redhat.com> From: Marc Orr Date: Mon, 25 Oct 2021 13:55:58 -0700 Message-ID: Subject: Re: [PATCH] KVM: SEV-ES: fix another issue with string I/O VMGEXITs To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 25, 2021 at 9:25 AM Paolo Bonzini wrote: > > If the guest requests string I/O from the hypervisor via VMGEXIT, > SW_EXITINFO2 will contain the REP count. However, sev_es_string_io > was incorrectly treating it as the size of the GHCB buffer in > bytes. > > This fixes the "outsw" test in the experimental SEV tests of > kvm-unit-tests. > > Cc: stable@vger.kernel.org > Fixes: 7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest") > Reported-by: Marc Orr > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/svm/sev.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index e672493b5d8d..12d29d669cbc 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -2579,11 +2579,16 @@ int sev_handle_vmgexit(struct kvm_vcpu *vcpu) > > int sev_es_string_io(struct vcpu_svm *svm, int size, unsigned int port, int in) > { > - if (!setup_vmgexit_scratch(svm, in, svm->vmcb->control.exit_info_2)) > + u32 bytes; > + > + if (unlikely(check_mul_overflow(svm->vmcb->control.exit_info_2, size, &bytes))) > + return -EINVAL; Maybe this is only an issue on our internal setup, but when I tested this I found that `check_mul_overflow()` is very particular that all three args having the same type. Therefore, to get it to compile, I changed all of the arguments to match the type of `exit_info_2`, like so: u64 bytes; if (unlikely(check_mul_overflow(svm->vmcb->control.exit_info_2, (u64)size, &bytes))) > + > + if (!setup_vmgexit_scratch(svm, in, bytes)) > return -EINVAL; > > - return kvm_sev_es_string_io(&svm->vcpu, size, port, > - svm->ghcb_sa, svm->ghcb_sa_len / size, in); > + return kvm_sev_es_string_io(&svm->vcpu, size, port, svm->ghcb_sa, > + svm->vmcb->control.exit_info_2, in); > } > > void sev_es_init_vmcb(struct vcpu_svm *svm) > -- > 2.27.0 > I've tested that this works. To test it, I (temporarily) modified `setup_vmgexit_scratch()` to always treat the scratch area as if it resides outside of the GHCB page (i.e., always go down the `else` code path). Doing this, I was able to see the stringio test case fail before this patch and pass with it. Reviewed-by: Marc Orr Tested-by: Marc Orr