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 1746BEB64DD for ; Fri, 23 Jun 2023 22:30:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231896AbjFWWa3 (ORCPT ); Fri, 23 Jun 2023 18:30:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230118AbjFWWa0 (ORCPT ); Fri, 23 Jun 2023 18:30:26 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74E3B172D for ; Fri, 23 Jun 2023 15:30:22 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-569e7aec37bso14193927b3.2 for ; Fri, 23 Jun 2023 15:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687559421; x=1690151421; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ppnF/aw1UnKTB9rbk7d1XJO3FUzzFPQL3mAmvvlJvvk=; b=MTDj+PfQEs89HXO3zua52f+xW70UlbpERfN9PVQS2ScE+E5cqLfBWGAeiFNwLI+h8W rnw02hXt7OWkMK4GD8ae4hlslf9skO74QM4px4MRHqYJTsbOhLPOcIgUocHbVtAFbyb2 LEuUv2xkfmEHiRMecz+e1Iwh1NALy7IdIK4Nvs13PhIrkKg1Q6hA9TH+4m947l8ftcFP ucN2XPaM8nRku3j+cae3v4t55rwmD76H75jFQzhvtNiw3xXKk/z6t6pK2pB42WeG97Rc +BDJ9dv30gyz0cEUazriP1GfHMYv6Sg4wfZIVgKzRLHDERIdNxr//tUbZVOfjwm9mncj D87g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687559421; x=1690151421; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ppnF/aw1UnKTB9rbk7d1XJO3FUzzFPQL3mAmvvlJvvk=; b=PZjVpsq2JDbdBVMuRYfntcIEBVzgiOlZ1l2oOrucbZALEjGrYC7nYLxxN1GYxXxFNW ReoJofpaoAsjudMc4vkZWCNlc8r2JJbqGIUDqoLFcs/kQhkEhVGqxIDDumeLJsQI1h/M t16SrH5Jm6g/yLpANM03SSmbUXVTRTuaDHJeSmYeRsmsqFFYA/Ld88uMB+NnM9TayhPT FG+5uE06H3VQ1jOaEUKaEpi6NDq9ZWUeNyhCoJMujudQ2+w2PEZY9pjV39nOnIVVuSsS 8nDfYWgjIevoxBEqtXlFSsTvLzd+LLNrfI0jKKYeDRKKFovj4KUOIWLxI6pNAEQYv/dI G3gA== X-Gm-Message-State: AC+VfDwANScjq6YzXdNVMOaB4HrpwKxcvXEG+IvejcA3Wobwc2ogWE3J gQ34hrIme7XKjQi6fnBZdRqZyhh23xM= X-Google-Smtp-Source: ACHHUZ5XST1V6QTVzRp4iXxtDryo3DAimovkh8fN5aBSif2NZ8wPonUnuPKMV/WXEiTr99p6wVqEVPNbQlU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a5b:711:0:b0:bac:fd27:28c1 with SMTP id g17-20020a5b0711000000b00bacfd2728c1mr9819038ybq.0.1687559421504; Fri, 23 Jun 2023 15:30:21 -0700 (PDT) Date: Fri, 23 Jun 2023 15:30:19 -0700 In-Reply-To: <20230511040857.6094-17-weijiang.yang@intel.com> Mime-Version: 1.0 References: <20230511040857.6094-1-weijiang.yang@intel.com> <20230511040857.6094-17-weijiang.yang@intel.com> Message-ID: Subject: Re: [PATCH v3 16/21] KVM:x86: Save/Restore GUEST_SSP to/from SMM state save area From: Sean Christopherson To: Yang Weijiang Cc: pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, peterz@infradead.org, rppt@kernel.org, binbin.wu@linux.intel.com, rick.p.edgecombe@intel.com, john.allen@amd.com Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 11, 2023, Yang Weijiang wrote: > Save GUEST_SSP to SMM state save area when guest exits to SMM > due to SMI and restore it VMCS field when guest exits SMM. This fails to answer "Why does KVM need to do this?" > Signed-off-by: Yang Weijiang > --- > arch/x86/kvm/smm.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/arch/x86/kvm/smm.c b/arch/x86/kvm/smm.c > index b42111a24cc2..c54d3eb2b7e4 100644 > --- a/arch/x86/kvm/smm.c > +++ b/arch/x86/kvm/smm.c > @@ -275,6 +275,16 @@ static void enter_smm_save_state_64(struct kvm_vcpu *vcpu, > enter_smm_save_seg_64(vcpu, &smram->gs, VCPU_SREG_GS); > > smram->int_shadow = static_call(kvm_x86_get_interrupt_shadow)(vcpu); > + > + if (kvm_cet_user_supported()) { This is wrong, KVM should not save/restore state that doesn't exist from the guest's perspective, i.e. this needs to check guest_cpuid_has(). On a related topic, I would love feedback on my series that adds a framework for features like this, where KVM needs to check guest CPUID as well as host support. https://lore.kernel.org/all/20230217231022.816138-1-seanjc@google.com > + struct msr_data msr; > + > + msr.index = MSR_KVM_GUEST_SSP; > + msr.host_initiated = true; Huh? > + /* GUEST_SSP is stored in VMCS at vm-exit. */ (a) this is not VMX code, i.e. referencing the VMCS is wrong, and (b) how the guest's SSP is managed is irrelevant, all that matters is that KVM can get the current guest value. > + static_call(kvm_x86_get_msr)(vcpu, &msr); > + smram->ssp = msr.data; > + } > } > #endif > > @@ -565,6 +575,16 @@ static int rsm_load_state_64(struct x86_emulate_ctxt *ctxt, > static_call(kvm_x86_set_interrupt_shadow)(vcpu, 0); > ctxt->interruptibility = (u8)smstate->int_shadow; > > + if (kvm_cet_user_supported()) { > + struct msr_data msr; > + > + msr.index = MSR_KVM_GUEST_SSP; > + msr.host_initiated = true; > + msr.data = smstate->ssp; > + /* Mimic host_initiated access to bypass ssp access check. */ No, masquerading as a host access is all kinds of wrong. I have no idea what check you're trying to bypass, but whatever it is, it's wrong. Per the SDM, the SSP field in SMRAM is writable, which means that KVM needs to correctly handle the scenario where SSP holds garbage, e.g. a non-canonical address. Why can't this use kvm_get_msr() and kvm_set_msr()?