From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Yang Weijiang <weijiang.yang@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, jmattson@google.com,
yu.c.zhang@linux.intel.com
Subject: Re: [PATCH v9 7/7] KVM: X86: Add user-space access interface for CET MSRs
Date: Tue, 3 Mar 2020 14:28:27 -0800 [thread overview]
Message-ID: <20200303222827.GC1439@linux.intel.com> (raw)
In-Reply-To: <20191227021133.11993-8-weijiang.yang@intel.com>
Subject should be something like "Enable CET virtualization", or maybe
move CPUID changes to a separate final patch?
On Fri, Dec 27, 2019 at 10:11:33AM +0800, Yang Weijiang wrote:
> There're two different places storing Guest CET states, states
> managed with XSAVES/XRSTORS, as restored/saved
> in previous patch, can be read/write directly from/to the MSRs.
> For those stored in VMCS fields, they're access via vmcs_read/
> vmcs_write.
>
> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
> ---
> arch/x86/include/asm/kvm_host.h | 3 +-
> arch/x86/kvm/cpuid.c | 5 +-
> arch/x86/kvm/vmx/vmx.c | 138 ++++++++++++++++++++++++++++++++
> arch/x86/kvm/x86.c | 11 +++
> 4 files changed, 154 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 64bf379381e4..34140462084f 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -90,7 +90,8 @@
> | X86_CR4_PGE | X86_CR4_PCE | X86_CR4_OSFXSR | X86_CR4_PCIDE \
> | X86_CR4_OSXSAVE | X86_CR4_SMEP | X86_CR4_FSGSBASE \
> | X86_CR4_OSXMMEXCPT | X86_CR4_LA57 | X86_CR4_VMXE \
> - | X86_CR4_SMAP | X86_CR4_PKE | X86_CR4_UMIP))
> + | X86_CR4_SMAP | X86_CR4_PKE | X86_CR4_UMIP \
> + | X86_CR4_CET))
>
> #define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 126a31b99823..4414bd110f3c 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -385,13 +385,14 @@ static inline void do_cpuid_7_mask(struct kvm_cpuid_entry2 *entry, int index)
> F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(RDPID) |
> F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) |
> F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) |
> - F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/;
> + F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | F(SHSTK) |
> + 0 /*WAITPKG*/;
>
> /* cpuid 7.0.edx*/
> const u32 kvm_cpuid_7_0_edx_x86_features =
> F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
> F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) |
> - F(MD_CLEAR);
> + F(MD_CLEAR) | F(IBT);
>
> /* cpuid 7.1.eax */
> const u32 kvm_cpuid_7_1_eax_x86_features =
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 0a75b65d03f0..52ac67604026 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -1763,6 +1763,96 @@ static int vmx_get_msr_feature(struct kvm_msr_entry *msr)
> return 0;
> }
>
> +#define CET_MSR_RSVD_BITS_1 0x3
> +#define CET_MSR_RSVD_BITS_2 (0xF << 6)
Would it make sense to use GENMASK?
> +static bool cet_ssp_write_allowed(struct kvm_vcpu *vcpu, struct msr_data *msr)
> +{
> + u64 data = msr->data;
> + u32 high_word = data >> 32;
> +
> + if (is_64_bit_mode(vcpu)) {
> + if (data & CET_MSR_RSVD_BITS_1)
This looks odd. I assume it should look more like cet_ctl_write_allowed()?
E.g.
if (data & CET_MSR_RSVD_BITS_1)
return false;
if (!is_64_bit_mode(vcpu) && high_word)
return false;
> + return false;
> + } else if (high_word) {
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static bool cet_ctl_write_allowed(struct kvm_vcpu *vcpu, struct msr_data *msr)
> +{
> + u64 data = msr->data;
> + u32 high_word = data >> 32;
> +
> + if (data & CET_MSR_RSVD_BITS_2)
> + return false;
> +
> + if (!is_64_bit_mode(vcpu) && high_word)
> + return false;
> +
> + return true;
> +}
> +
> +static bool cet_ssp_access_allowed(struct kvm_vcpu *vcpu, struct msr_data *msr)
> +{
> + u64 kvm_xss;
> + u32 index = msr->index;
> +
> + if (is_guest_mode(vcpu))
Hmm, this seems wrong, e.g. shouldn't WRMSR be allowed if L1 passes the MSR
to L2, which is the only way to reach this, if I'm not mistaken.
> + return false;
> +
> + if (!boot_cpu_has(X86_FEATURE_SHSTK))
> + return false;
> +
> + if (!msr->host_initiated &&
> + !guest_cpuid_has(vcpu, X86_FEATURE_SHSTK))
> + return false;
> +
> + if (index == MSR_IA32_INT_SSP_TAB)
> + return true;
> +
> + kvm_xss = kvm_supported_xss();
> +
> + if (index == MSR_IA32_PL3_SSP) {
> + if (!(kvm_xss & XFEATURE_MASK_CET_USER))
> + return false;
> + } else if (!(kvm_xss & XFEATURE_MASK_CET_KERNEL)) {
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static bool cet_ctl_access_allowed(struct kvm_vcpu *vcpu, struct msr_data *msr)
> +{
> + u64 kvm_xss;
> + u32 index = msr->index;
> +
> + if (is_guest_mode(vcpu))
> + return false;
> +
> + kvm_xss = kvm_supported_xss();
> +
> + if (!boot_cpu_has(X86_FEATURE_SHSTK) &&
> + !boot_cpu_has(X86_FEATURE_IBT))
> + return false;
> +
> + if (!msr->host_initiated &&
> + !guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) &&
> + !guest_cpuid_has(vcpu, X86_FEATURE_IBT))
> + return false;
> +
> + if (index == MSR_IA32_U_CET) {
> + if (!(kvm_xss & XFEATURE_MASK_CET_USER))
> + return false;
> + } else if (!(kvm_xss & XFEATURE_MASK_CET_KERNEL)) {
> + return false;
> + }
> +
> + return true;
> +}
> /*
> * Reads an msr value (of 'msr_index') into 'pdata'.
> * Returns 0 on success, non-0 otherwise.
> @@ -1886,6 +1976,26 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> else
> msr_info->data = vmx->pt_desc.guest.addr_a[index / 2];
> break;
> + case MSR_IA32_S_CET:
> + if (!cet_ctl_access_allowed(vcpu, msr_info))
> + return 1;
> + msr_info->data = vmcs_readl(GUEST_S_CET);
> + break;
> + case MSR_IA32_INT_SSP_TAB:
> + if (!cet_ssp_access_allowed(vcpu, msr_info))
> + return 1;
> + msr_info->data = vmcs_readl(GUEST_INTR_SSP_TABLE);
> + break;
> + case MSR_IA32_U_CET:
> + if (!cet_ctl_access_allowed(vcpu, msr_info))
> + return 1;
> + rdmsrl(MSR_IA32_U_CET, msr_info->data);
> + break;
> + case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
> + if (!cet_ssp_access_allowed(vcpu, msr_info))
> + return 1;
> + rdmsrl(msr_info->index, msr_info->data);
Ugh, thought of another problem. If a SoftIRQ runs after an IRQ it can
load the kernel FPU state. So for all the XSAVES MSRs we'll need a helper
similar to vmx_write_guest_kernel_gs_base(), except XSAVES has to be even
more restrictive and disable IRQs entirely. E.g.
static void vmx_get_xsave_msr(struct msr_data *msr_info)
{
local_irq_disable();
if (test_thread_flag(TIF_NEED_FPU_LOAD))
switch_fpu_return();
rdmsrl(msr_info->index, msr_info->data);
local_irq_enable();
}
> + break;
> case MSR_TSC_AUX:
> if (!msr_info->host_initiated &&
> !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP))
> @@ -2147,6 +2257,34 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> else
> vmx->pt_desc.guest.addr_a[index / 2] = data;
> break;
> + case MSR_IA32_S_CET:
> + if (!cet_ctl_access_allowed(vcpu, msr_info))
> + return 1;
> + if (!cet_ctl_write_allowed(vcpu, msr_info))
> + return 1;
> + vmcs_writel(GUEST_S_CET, data);
> + break;
> + case MSR_IA32_INT_SSP_TAB:
> + if (!cet_ctl_access_allowed(vcpu, msr_info))
> + return 1;
> + if (!is_64_bit_mode(vcpu))
> + return 1;
> + vmcs_writel(GUEST_INTR_SSP_TABLE, data);
> + break;
> + case MSR_IA32_U_CET:
> + if (!cet_ctl_access_allowed(vcpu, msr_info))
> + return 1;
> + if (!cet_ctl_write_allowed(vcpu, msr_info))
> + return 1;
> + wrmsrl(MSR_IA32_U_CET, data);
> + break;
> + case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
> + if (!cet_ssp_access_allowed(vcpu, msr_info))
> + return 1;
> + if (!cet_ssp_write_allowed(vcpu, msr_info))
> + return 1;
> + wrmsrl(msr_info->index, data);
> + break;
> case MSR_TSC_AUX:
> if (!msr_info->host_initiated &&
> !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP))
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 6dbe77365b22..7de6faa6aa51 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1186,6 +1186,10 @@ static const u32 msrs_to_save_all[] = {
> MSR_ARCH_PERFMON_EVENTSEL0 + 12, MSR_ARCH_PERFMON_EVENTSEL0 + 13,
> MSR_ARCH_PERFMON_EVENTSEL0 + 14, MSR_ARCH_PERFMON_EVENTSEL0 + 15,
> MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,
> +
> + MSR_IA32_XSS, MSR_IA32_U_CET, MSR_IA32_S_CET,
> + MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP,
> + MSR_IA32_PL3_SSP, MSR_IA32_INT_SSP_TAB,
> };
>
> static u32 msrs_to_save[ARRAY_SIZE(msrs_to_save_all)];
> @@ -1468,6 +1472,13 @@ static int __kvm_set_msr(struct kvm_vcpu *vcpu, u32 index, u64 data,
> * invokes 64-bit SYSENTER.
> */
> data = get_canonical(data, vcpu_virt_addr_bits(vcpu));
> + break;
> + case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
> + case MSR_IA32_U_CET:
> + case MSR_IA32_S_CET:
> + case MSR_IA32_INT_SSP_TAB:
> + if (is_noncanonical_address(data, vcpu))
> + return 1;
> }
>
> msr.data = data;
> --
> 2.17.2
>
next prev parent reply other threads:[~2020-03-03 22:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-27 2:11 [PATCH v9 0/7] Introduce support for guest CET feature Yang Weijiang
2019-12-27 2:11 ` [PATCH v9 1/7] KVM: CPUID: Fix IA32_XSS support in CPUID(0xd,i) enumeration Yang Weijiang
2020-03-05 14:51 ` Paolo Bonzini
2020-03-06 0:38 ` Yang Weijiang
2019-12-27 2:11 ` [PATCH v9 2/7] KVM: VMX: Define CET VMCS fields and #CP flag Yang Weijiang
2020-03-03 21:42 ` Sean Christopherson
2020-03-04 8:44 ` Yang Weijiang
2019-12-27 2:11 ` [PATCH v9 3/7] KVM: VMX: Pass through CET related MSRs Yang Weijiang
2020-03-03 21:51 ` Sean Christopherson
2020-03-04 8:46 ` Yang Weijiang
2019-12-27 2:11 ` [PATCH v9 4/7] KVM: VMX: Load CET states on vmentry/vmexit Yang Weijiang
2020-03-03 22:06 ` Sean Christopherson
2020-03-04 8:55 ` Yang Weijiang
2019-12-27 2:11 ` [PATCH v9 5/7] KVM: X86: Enable CET bits update in IA32_XSS Yang Weijiang
2019-12-27 2:11 ` [PATCH v9 6/7] KVM: X86: Load guest fpu state when accessing MSRs managed by XSAVES Yang Weijiang
2019-12-27 2:11 ` [PATCH v9 7/7] KVM: X86: Add user-space access interface for CET MSRs Yang Weijiang
2020-03-03 22:28 ` Sean Christopherson [this message]
2020-03-04 15:18 ` Yang Weijiang
2020-03-04 15:45 ` Sean Christopherson
2020-03-05 12:31 ` Yang Weijiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200303222827.GC1439@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=weijiang.yang@intel.com \
--cc=yu.c.zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox