Received: by 2002:a05:7412:b795:b0:e2:908c:2ebd with SMTP id iv21csp578568rdb; Thu, 2 Nov 2023 11:39:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGdXuaG1ZsIDWPvxVm+qQk8V2x7AQt+ekVRD66t0QCDifdklamcxhHIhEkR7XGRoDdDvr39 X-Received: by 2002:a05:6a00:1307:b0:690:3a0f:4164 with SMTP id j7-20020a056a00130700b006903a0f4164mr17052367pfu.19.1698950357073; Thu, 02 Nov 2023 11:39:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698950357; cv=none; d=google.com; s=arc-20160816; b=xLovGN0b44HUuFMqgYwgf1vI8bY/nXH5bWrWeBxnrZkBbx2SOvaRS/mOszNQcTYoN/ zt8lwIxsriaxMfL57QOR0VR5HZAgYx08FC93dwCd/QATtEEdrrwYs09GzPD0jcfAncGB FyWqmfBZ7kqt5xckVMV1DaJBBlVAlReudxsUAylr+fKUCD7FOaDRWH7pjo7MGebMzT6t gcry+HO+2100irosETdSzSg30pw5lSxko9IjKZEcKQJVrBG/hkrb5r9F2uBUIMZUp/35 4XqeU1nSPyNu8JkCxuclO1lkL7jsiIIYKyH8Bzs5atAPWQ+WMrl3PP8gbzh4G+j8MJWa or5A== 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 :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=gcxyLn+j42pQ4O/S+kERc6I/oidQhojoanYwpge7F0M=; fh=mJ0TIX4nXG/bpZwgk02WmB2EtK+oEU7bGXa6nt45zMY=; b=Iv3lFAwpM+fj4KXNTrlLKlyGtHYvesOrJLVbgfbXt6wl6xfdPc4D19WSzxjbJ2x5mG ybQ/e29DM4qI7stkh1XTVbgN3Sc0i7EKYuH+ef9ZiI0oirsFyDJvZv8GaFzYTi2TdG1u Bo0gAy/ExPY1h16dcNYztd2iWMcqC6ozyQ8pDLvYm/1LgD/49T+KmrzhpVNku01P9TqX /06T4fWBi6sfOD6ycQxhcmgG3Tlk4wWTpp/60zCY7yDyEIjyty0Jl6VOlRknpOYD0c25 8Bj+xh9KdFj87yljRsk1heYr1d642mWG3/BR0I/xB3z4pjn1r2Me8LFtSlrpAJQ7Wt2R 0VhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EQ1WMGB1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id s6-20020a056a00178600b006bd4013fdffsi111562pfg.241.2023.11.02.11.39.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Nov 2023 11:39:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EQ1WMGB1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id F356982CAC16; Thu, 2 Nov 2023 11:39:15 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377335AbjKBSjO (ORCPT + 99 others); Thu, 2 Nov 2023 14:39:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377254AbjKBSjM (ORCPT ); Thu, 2 Nov 2023 14:39:12 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CDC2191 for ; Thu, 2 Nov 2023 11:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698950299; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gcxyLn+j42pQ4O/S+kERc6I/oidQhojoanYwpge7F0M=; b=EQ1WMGB1YOwVgGItqHt1x0ehiKTudIGLn1ZYbmPukiSolgrshqxD5Kiyt5T50r3SgdGsIE Zlx99QX+pvV/49kwGeqgYI1wA4+741Lyx9mP9YUgIZCAkhqMGhi7pN5orrfi5NAJSa2c1q Of8GAtHkZU2qorcLOiNdqJjthK/fqCM= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-112-IlLozxYiOGWfGWh7TxgZnA-1; Thu, 02 Nov 2023 14:38:17 -0400 X-MC-Unique: IlLozxYiOGWfGWh7TxgZnA-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2c53c85e482so13917671fa.1 for ; Thu, 02 Nov 2023 11:38:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698950295; x=1699555095; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gcxyLn+j42pQ4O/S+kERc6I/oidQhojoanYwpge7F0M=; b=OvR/7/mH66iBu4wg4qOJXV37yNuqKMFsBXZG17nIfYrb1vxp2Y9oZB6zDk929zcrfa Mdk8HAjQWCTCy1srlj20MgurzVHmAUzGf+bwA042prVW3c7kOHUThy/LosHfGWrDUDqq dZLfsqH4xY6mFW43D6g6VJGcxYDFcDrTcZTGNsgfKWG7YkmqtORfgZan4ZTFjHNEAmfK zd4LBNlwo+kWX60M0XwX7jSpjRVAjiTlc1Af0TfKyMg+9XaUlrJvfZRw14oYktziNaJw WZGJekkpLdQRJ53znxh9DMyNJOnrw2whnFqQaqP/8SPub+9/Jd6NppJTjG3995IUYT7N jflA== X-Gm-Message-State: AOJu0Yxi3Ja205ONPoPLZrUZcY7O1aQuG250/OI96H5rW4G/OlTq3mBp PFaMUJ1q9t7g2pA4RZf02IqtvS4j6oPCwfCZdUt7peP8FY/i92NAz2cAGmxu/db0RPVfcyrSEVV ImFygVtn2aLLV6slyOdldFzut X-Received: by 2002:a2e:9246:0:b0:2c5:724:fd64 with SMTP id v6-20020a2e9246000000b002c50724fd64mr14938878ljg.46.1698950295631; Thu, 02 Nov 2023 11:38:15 -0700 (PDT) X-Received: by 2002:a2e:9246:0:b0:2c5:724:fd64 with SMTP id v6-20020a2e9246000000b002c50724fd64mr14938863ljg.46.1698950295255; Thu, 02 Nov 2023 11:38:15 -0700 (PDT) Received: from starship ([89.237.99.95]) by smtp.gmail.com with ESMTPSA id p22-20020a05600c1d9600b004060f0a0fd5sm328240wms.13.2023.11.02.11.38.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Nov 2023 11:38:14 -0700 (PDT) Message-ID: Subject: Re: [PATCH v6 19/25] KVM: VMX: Emulate read and write to CET MSRs From: Maxim Levitsky To: Sean Christopherson Cc: Yang Weijiang , pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, dave.hansen@intel.com, peterz@infradead.org, chao.gao@intel.com, rick.p.edgecombe@intel.com, john.allen@amd.com Date: Thu, 02 Nov 2023 20:38:12 +0200 In-Reply-To: References: <20230914063325.85503-1-weijiang.yang@intel.com> <20230914063325.85503-20-weijiang.yang@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 02 Nov 2023 11:39:16 -0700 (PDT) On Wed, 2023-11-01 at 09:31 -0700, Sean Christopherson wrote: > On Tue, Oct 31, 2023, Maxim Levitsky wrote: > > On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote: > > > Add emulation interface for CET MSR access. The emulation code is split > > > into common part and vendor specific part. The former does common check > > > for MSRs and reads/writes directly from/to XSAVE-managed MSRs via the > > > helpers while the latter accesses the MSRs linked to VMCS fields. > > > > > > Signed-off-by: Yang Weijiang > > > --- > > ... > > > > + case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP: > > > + case MSR_KVM_SSP: > > > + if (host_msr_reset && kvm_cpu_cap_has(X86_FEATURE_SHSTK)) > > > + break; > > > + if (!guest_can_use(vcpu, X86_FEATURE_SHSTK)) > > > + return 1; > > > + if (index == MSR_KVM_SSP && !host_initiated) > > > + return 1; > > > + if (is_noncanonical_address(data, vcpu)) > > > + return 1; > > > + if (index != MSR_IA32_INT_SSP_TAB && !IS_ALIGNED(data, 4)) > > > + return 1; > > > + break; > > Once again I'll prefer to have an ioctl for setting/getting SSP, this will > > make the above code simpler (e.g there will be no need to check that write > > comes from the host/etc). > > I don't think an ioctl() would be simpler overall, especially when factoring in > userspace. With a synthetic MSR, we get the following quite cheaply: > > 1. Enumerating support to userspace. > 2. Save/restore of the value, e.g. for live migration. > 3. Vendor hooks for propagating values to/from the VMCS/VMCB. > > For an ioctl(), > #1 would require a capability, #2 (and #1 to some extent) would > require new userspace flows, and #3 would require new kvm_x86_ops hooks. > > The synthetic MSR adds a small amount of messiness, as does bundling > MSR_IA32_INT_SSP_TAB with the other shadow stack MSRs. The bulk of the mess comes > from the need to allow userspace to write '0' when KVM enumerated supported to > userspace. Let me put it this way - all hacks start like that, and in this case this is API/ABI hack so we will have to live with it forever. Once there is a precedent, trust me there will be 10s of new 'fake' msrs added, and the interface will become one big mess. As I suggested, if you don't want to add new capability/ioctl and vendor callback per new x86 arch register, then let's implement KVM_GET_ONE_REG/KVM_SET_ONE_REG and then it will be really easy to add new regs without confusing users, and without polluting msr namespace with msrs that don't exist. Best regards, Maxim Levitsky > > If we isolate MSR_IA32_INT_SSP_TAB, that'll help with the synthetic MSR and with > MSR_IA32_INT_SSP_TAB. For the unfortunate "host reset" behavior, the best idea I > came up with is to add a helper. It's still a bit ugly, but the ugliness is > contained in a helper and IMO makes it much easier to follow the case statements. > > get: > > case MSR_IA32_INT_SSP_TAB: > if (!guest_can_use(vcpu, X86_FEATURE_SHSTK) || > !guest_cpuid_has(vcpu, X86_FEATURE_LM)) > return 1; > break; > case MSR_KVM_SSP: > if (!host_initiated) > return 1; > fallthrough; > case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP: > if (!guest_can_use(vcpu, X86_FEATURE_SHSTK)) > return 1; > break; > > static bool is_set_cet_msr_allowed(struct kvm_vcpu *vcpu, u32 index, u64 data, > bool host_initiated) > { > bool any_cet = index == MSR_IA32_S_CET || index == MSR_IA32_U_CET; > > if (guest_can_use(vcpu, X86_FEATURE_SHSTK)) > return true; > > if (any_cet && guest_can_use(vcpu, X86_FEATURE_IBT)) > return true; > > /* > * If KVM supports the MSR, i.e. has enumerated the MSR existence to > * userspace, then userspace is allowed to write '0' irrespective of > * whether or not the MSR is exposed to the guest. > */ > if (!host_initiated || data) > return false; > > if (kvm_cpu_cap_has(X86_FEATURE_SHSTK)) > return true; > > return any_cet && kvm_cpu_cap_has(X86_FEATURE_IBT); > } > > set: > case MSR_IA32_U_CET: > case MSR_IA32_S_CET: > if (!is_set_cet_msr_allowed(vcpu, index, data, host_initiated)) > return 1; > if (data & CET_US_RESERVED_BITS) > return 1; > if (!guest_can_use(vcpu, X86_FEATURE_SHSTK) && > (data & CET_US_SHSTK_MASK_BITS)) > return 1; > if (!guest_can_use(vcpu, X86_FEATURE_IBT) && > (data & CET_US_IBT_MASK_BITS)) > return 1; > if (!IS_ALIGNED(CET_US_LEGACY_BITMAP_BASE(data), 4)) > return 1; > > /* IBT can be suppressed iff the TRACKER isn't WAIT_ENDBR. */ > if ((data & CET_SUPPRESS) && (data & CET_WAIT_ENDBR)) > return 1; > break; > case MSR_IA32_INT_SSP_TAB: > if (!guest_cpuid_has(vcpu, X86_FEATURE_LM)) > return 1; > > if (is_noncanonical_address(data, vcpu)) > return 1; > break; > case MSR_KVM_SSP: > if (!host_initiated) > return 1; > fallthrough; > case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP: > if (!is_set_cet_msr_allowed(vcpu, index, data, host_initiated)) > return 1; > if (is_noncanonical_address(data, vcpu)) > return 1; > if (!IS_ALIGNED(data, 4)) > return 1; > break; > } >