From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05EC1C433EF for ; Tue, 14 Jun 2022 21:58:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352656AbiFNV6y (ORCPT ); Tue, 14 Jun 2022 17:58:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356793AbiFNV6i (ORCPT ); Tue, 14 Jun 2022 17:58:38 -0400 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E06022538 for ; Tue, 14 Jun 2022 14:58:36 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id 92-20020a17090a09e500b001d917022847so4186712pjo.1 for ; Tue, 14 Jun 2022 14:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=ebS8dne3mnDpirg5LR725mOTZXQcHNFKEGxHVUOffsM=; b=VOwSyBvRR60i3AzxCfJhD5+jngE1w8CYRvv8U8CK6pDoMBqQQF3kymLu/Jhj/Ht8Wu tsUDCkoUg3wR2qxrZlzyReHtjtB/Ue0KVWcMHJO232lmeNnTU0jmy5LHaNksHjvBKOqj A3mZlVivN46URKThiboEbJrzzdyRLdzI0mnFc7JGTBd3Fl6BfSJ1Bu0/2mhq7FJbkwBW n0ULn4Mj4aH+laV/eA5fLJqPbrVXsioPLv60mDy0bBQRkPGatFGl282hjjDcviWkkh1h C7jke03Z+rNSjxHv/WhUudNUhUT/73YExrWmzV2ypLTeiq+OpVM4priwcbU77a3K++o+ W6UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=ebS8dne3mnDpirg5LR725mOTZXQcHNFKEGxHVUOffsM=; b=yTlV9ot5W4MBp07fejdp0DrWCPossyTXKKsCPvovg/gtMNGF0jAcYPg37Y2/EyH71d PVj0mcXhqrg/nc57FUqtQGFrGOjbANAScJbyjcAbZkTZGFd0dxb96LXHy5ZVagDUAYn2 Fq0kqPwbMLQz8j/mgCgGQrFXsNliL4QLpk5dQnFfE0BPWCrnDhQZncX1cMRkiqaZtufp 8b/qMubtt5Nybw1JYYnnBeDXWmeAScHetRJnW9v3b+lr87ffzNAcUcW68pJPCCwYIGcq TRQ/iICu/RUPd3Hji9ZvAD/r5/zt/NoG0cqfe/nI3fmZzlslwApVd+2YOEUi0btutBM5 7PRQ== X-Gm-Message-State: AJIora93OiCVSBPMtAc2VB7IM31cf0VIemvYJxndKFdvOpaKL9EYD9wD hufze8J1Y+whXQdecpvvDPNsC85mA4A= X-Google-Smtp-Source: AGRyM1vMQ6nhSdUpnQYVSpnpt2k+LMXtZ71PU0X63rWRBPPfkzBD6InMr8CLS1qvxKaEQ0bcMvu1i2cChow= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:902:64c2:b0:168:c298:bdee with SMTP id y2-20020a17090264c200b00168c298bdeemr6090894pli.82.1655243916084; Tue, 14 Jun 2022 14:58:36 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 14 Jun 2022 21:58:27 +0000 In-Reply-To: <20220614215831.3762138-1-seanjc@google.com> Message-Id: <20220614215831.3762138-2-seanjc@google.com> Mime-Version: 1.0 References: <20220614215831.3762138-1-seanjc@google.com> X-Mailer: git-send-email 2.36.1.476.g0c4daa206d-goog Subject: [PATCH 1/5] KVM: nVMX: Snapshot pre-VM-Enter BNDCFGS for !nested_run_pending case From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Lei Wang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If a nested run isn't pending, snapshot vmcs01.GUEST_BNDCFGS irrespective of whether or not VM_ENTRY_LOAD_BNDCFGS is set in vmcs12. When restoring nested state, e.g. after migration, without a nested run pending, prepare_vmcs02() will propagate nested.vmcs01_guest_bndcfgs to vmcs02, i.e. will load garbage/zeros into vmcs02.GUEST_BNDCFGS. If userspace restores nested state before MSRs, then loading garbage is a non-issue as loading BNDCFGS will also update vmcs02. But if usersepace restores MSRs first, then KVM is responsible for propagating L2's value, which is actually thrown into vmcs01, into vmcs02. Restoring L2 MSRs into vmcs01, i.e. loading all MSRs before nested state is all kinds of bizarre and ideally would not be supported. Sadly, some VMMs do exactly that and rely on KVM to make things work. Note, there's still a lurking SMM bug, as propagating vmcs01.GUEST_BNDFGS to vmcs02 across RSM may corrupt L2's BNDCFGS. But KVM's entire VMX+SMM emulation is flawed as SMI+RSM should not toouch _any_ VMCS when use the "default treatment of SMIs", i.e. when not using an SMI Transfer Monitor. Link: https://lore.kernel.org/all/Yobt1XwOfb5M6Dfa@google.com Fixes: 62cf9bd8118c ("KVM: nVMX: Fix emulation of VM_ENTRY_LOAD_BNDCFGS") Cc: stable@vger.kernel.org Cc: Lei Wang Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/nested.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 7d8cd0ebcc75..66c25bb56938 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -3382,7 +3382,8 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu, if (!(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_DEBUG_CONTROLS)) vmx->nested.vmcs01_debugctl = vmcs_read64(GUEST_IA32_DEBUGCTL); if (kvm_mpx_supported() && - !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS)) + (!vmx->nested.nested_run_pending || + !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))) vmx->nested.vmcs01_guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS); /* -- 2.36.1.476.g0c4daa206d-goog