Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1441678 > unrolled thread

[RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP

Started byPaolo Bonzini <pbonzini@redhat.com>
First post2016-07-12 21:30 +0200
Last post2016-07-14 15:00 +0200
Articles 11 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Paolo Bonzini <pbonzini@redhat.com> - 2016-07-12 21:30 +0200
    Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Yang Zhang <yang.zhang.wz@gmail.com> - 2016-07-13 11:30 +0200
      Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Paolo Bonzini <pbonzini@redhat.com> - 2016-07-13 11:40 +0200
        Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Yang Zhang <yang.zhang.wz@gmail.com> - 2016-07-13 12:00 +0200
      Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Paolo Bonzini <pbonzini@redhat.com> - 2016-07-13 11:40 +0200
        Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Yang Zhang <yang.zhang.wz@gmail.com> - 2016-07-13 12:10 +0200
          Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Paolo Bonzini <pbonzini@redhat.com> - 2016-07-13 12:30 +0200
    Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Radim Krčmář <rkrcmar@redhat.com> - 2016-07-13 22:40 +0200
      Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Paolo Bonzini <pbonzini@redhat.com> - 2016-07-14 10:20 +0200
        Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Radim Krčmář <rkrcmar@redhat.com> - 2016-07-14 14:40 +0200
          Re: [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP Paolo Bonzini <pbonzini@redhat.com> - 2016-07-14 15:00 +0200

#1441678 — [RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-07-12 21:30 +0200
Subject[RFC PATCH 4/4] KVM: vmx: add support for emulating UMIP
Message-ID<rUbxw-Oh-27@gated-at.bofh.it>
UMIP (User-Mode Instruction Prevention) is a feature of future
Intel processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT
and SMSW from user-mode processes.

On Intel systems it's *almost* possible to emulate it; it slows
down the instructions when they're executed in ring 0, but they
are really never executed in practice.  The catch is that SMSW
doesn't cause a vmexit, and hence SMSW will not fault.

When UMIP is enabled but not supported by the host, descriptor table
exits are enabled, and the emulator takes care of injecting a #GP when
any of SLDT, SGDT, STR, SIDT are encountered.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 arch/x86/include/asm/vmx.h      |  1 +
 arch/x86/include/uapi/asm/vmx.h |  4 ++++
 arch/x86/kvm/vmx.c              | 36 ++++++++++++++++++++++++++++++++++--
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 14c63c7e8337..8b95f0ec0190 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -60,6 +60,7 @@
  */
 #define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x00000001
 #define SECONDARY_EXEC_ENABLE_EPT               0x00000002
+#define SECONDARY_EXEC_DESC			0x00000004
 #define SECONDARY_EXEC_RDTSCP			0x00000008
 #define SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x00000010
 #define SECONDARY_EXEC_ENABLE_VPID              0x00000020
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 5b15d94a33f8..2f9a69b9559c 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -65,6 +65,8 @@
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
 #define EXIT_REASON_EOI_INDUCED         45
+#define EXIT_REASON_GDTR_IDTR           46
+#define EXIT_REASON_LDTR_TR             47
 #define EXIT_REASON_EPT_VIOLATION       48
 #define EXIT_REASON_EPT_MISCONFIG       49
 #define EXIT_REASON_INVEPT              50
@@ -114,6 +116,8 @@
 	{ EXIT_REASON_MCE_DURING_VMENTRY,    "MCE_DURING_VMENTRY" }, \
 	{ EXIT_REASON_TPR_BELOW_THRESHOLD,   "TPR_BELOW_THRESHOLD" }, \
 	{ EXIT_REASON_APIC_ACCESS,           "APIC_ACCESS" }, \
+	{ EXIT_REASON_GDTR_IDTR,	     "GDTR_IDTR" }, \
+	{ EXIT_REASON_LDTR_TR,		     "LDTR_TR" }, \
 	{ EXIT_REASON_EPT_VIOLATION,         "EPT_VIOLATION" }, \
 	{ EXIT_REASON_EPT_MISCONFIG,         "EPT_MISCONFIG" }, \
 	{ EXIT_REASON_INVEPT,                "INVEPT" }, \
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b133fc3d6a7d..0706e363c5e3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3342,6 +3342,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf)
 			SECONDARY_EXEC_ENABLE_EPT |
 			SECONDARY_EXEC_UNRESTRICTED_GUEST |
 			SECONDARY_EXEC_PAUSE_LOOP_EXITING |
+			SECONDARY_EXEC_DESC |
 			SECONDARY_EXEC_RDTSCP |
 			SECONDARY_EXEC_ENABLE_INVPCID |
 			SECONDARY_EXEC_APIC_REGISTER_VIRT |
@@ -3967,6 +3968,14 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
 		(to_vmx(vcpu)->rmode.vm86_active ?
 		 KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON);
 
+	if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
+		vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
+			      SECONDARY_EXEC_DESC);
+		hw_cr4 &= ~X86_CR4_UMIP;
+	} else
+		vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
+				SECONDARY_EXEC_DESC);
+
 	if (cr4 & X86_CR4_VMXE) {
 		/*
 		 * To use VMXON (and later other VMX instructions), a guest
@@ -4913,6 +4922,11 @@ static u32 vmx_exec_control(struct vcpu_vmx *vmx)
 static u32 vmx_secondary_exec_control(struct vcpu_vmx *vmx)
 {
 	u32 exec_control = vmcs_config.cpu_based_2nd_exec_ctrl;
+
+	/* SECONDARY_EXEC_DESC is enabled/disabled on writes to CR4.UMIP,
+	 * in vmx_set_cr4.  */
+	exec_control &= ~SECONDARY_EXEC_DESC;
+
 	if (!cpu_need_virtualize_apic_accesses(&vmx->vcpu))
 		exec_control &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
 	if (vmx->vpid == 0)
@@ -5649,6 +5663,12 @@ static void handle_clts(struct kvm_vcpu *vcpu)
 		vmx_set_cr0(vcpu, kvm_read_cr0_bits(vcpu, ~X86_CR0_TS));
 }
 
+static int handle_desc(struct kvm_vcpu *vcpu)
+{
+	WARN_ON(!(vcpu->arch.cr4 & X86_CR4_UMIP));
+	return emulate_instruction(vcpu, 0) == EMULATE_DONE;
+}
+
 static int handle_cr(struct kvm_vcpu *vcpu)
 {
 	unsigned long exit_qualification, val;
@@ -7705,6 +7731,8 @@ static int (*const kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = {
 	[EXIT_REASON_XSETBV]                  = handle_xsetbv,
 	[EXIT_REASON_TASK_SWITCH]             = handle_task_switch,
 	[EXIT_REASON_MCE_DURING_VMENTRY]      = handle_machine_check,
+	[EXIT_REASON_GDTR_IDTR]		      = handle_desc,
+	[EXIT_REASON_LDTR_TR]		      = handle_desc,
 	[EXIT_REASON_EPT_VIOLATION]	      = handle_ept_violation,
 	[EXIT_REASON_EPT_MISCONFIG]           = handle_ept_misconfig,
 	[EXIT_REASON_PAUSE_INSTRUCTION]       = handle_pause,
@@ -7972,6 +8000,8 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu)
 		return nested_cpu_has(vmcs12, CPU_BASED_MOV_DR_EXITING);
 	case EXIT_REASON_IO_INSTRUCTION:
 		return nested_vmx_exit_handled_io(vcpu, vmcs12);
+	case EXIT_REASON_GDTR_IDTR: case EXIT_REASON_LDTR_TR:
+		return nested_cpu_has2(vmcs12, SECONDARY_EXEC_DESC);
 	case EXIT_REASON_MSR_READ:
 	case EXIT_REASON_MSR_WRITE:
 		return nested_vmx_exit_handled_msr(vcpu, vmcs12, exit_reason);
@@ -8597,7 +8627,8 @@ static bool vmx_xsaves_supported(void)
 
 static bool vmx_umip_emulated(void)
 {
-	return false;
+	return vmcs_config.cpu_based_2nd_exec_ctrl &
+		SECONDARY_EXEC_DESC;
 }
 
 static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx)
@@ -9173,7 +9204,8 @@ static void vmcs_set_secondary_exec_control(u32 new_ctl)
 	u32 mask =
 		SECONDARY_EXEC_SHADOW_VMCS |
 		SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
-		SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+		SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
+		SECONDARY_EXEC_DESC;
 
 	u32 cur_ctl = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
 
-- 
1.8.3.1

[toc] | [next] | [standalone]

#1442255

FromYang Zhang <yang.zhang.wz@gmail.com>
Date2016-07-13 11:30 +0200
Message-ID<rUoEp-13x-17@gated-at.bofh.it>
In reply to#1441678
On 2016/7/13 3:20, Paolo Bonzini wrote:
> UMIP (User-Mode Instruction Prevention) is a feature of future
> Intel processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT
> and SMSW from user-mode processes.
>
> On Intel systems it's *almost* possible to emulate it; it slows
> down the instructions when they're executed in ring 0, but they
> are really never executed in practice.  The catch is that SMSW
> doesn't cause a vmexit, and hence SMSW will not fault.
>
> When UMIP is enabled but not supported by the host, descriptor table
> exits are enabled, and the emulator takes care of injecting a #GP when
> any of SLDT, SGDT, STR, SIDT are encountered.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  arch/x86/include/asm/vmx.h      |  1 +
>  arch/x86/include/uapi/asm/vmx.h |  4 ++++
>  arch/x86/kvm/vmx.c              | 36 ++++++++++++++++++++++++++++++++++--
>  3 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> index 14c63c7e8337..8b95f0ec0190 100644
> --- a/arch/x86/include/asm/vmx.h
> +++ b/arch/x86/include/asm/vmx.h
> @@ -60,6 +60,7 @@
>   */
>  #define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x00000001
>  #define SECONDARY_EXEC_ENABLE_EPT               0x00000002
> +#define SECONDARY_EXEC_DESC			0x00000004
>  #define SECONDARY_EXEC_RDTSCP			0x00000008
>  #define SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x00000010
>  #define SECONDARY_EXEC_ENABLE_VPID              0x00000020
> diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
> index 5b15d94a33f8..2f9a69b9559c 100644
> --- a/arch/x86/include/uapi/asm/vmx.h
> +++ b/arch/x86/include/uapi/asm/vmx.h
> @@ -65,6 +65,8 @@
>  #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
>  #define EXIT_REASON_APIC_ACCESS         44
>  #define EXIT_REASON_EOI_INDUCED         45
> +#define EXIT_REASON_GDTR_IDTR           46
> +#define EXIT_REASON_LDTR_TR             47
>  #define EXIT_REASON_EPT_VIOLATION       48
>  #define EXIT_REASON_EPT_MISCONFIG       49
>  #define EXIT_REASON_INVEPT              50
> @@ -114,6 +116,8 @@
>  	{ EXIT_REASON_MCE_DURING_VMENTRY,    "MCE_DURING_VMENTRY" }, \
>  	{ EXIT_REASON_TPR_BELOW_THRESHOLD,   "TPR_BELOW_THRESHOLD" }, \
>  	{ EXIT_REASON_APIC_ACCESS,           "APIC_ACCESS" }, \
> +	{ EXIT_REASON_GDTR_IDTR,	     "GDTR_IDTR" }, \
> +	{ EXIT_REASON_LDTR_TR,		     "LDTR_TR" }, \
>  	{ EXIT_REASON_EPT_VIOLATION,         "EPT_VIOLATION" }, \
>  	{ EXIT_REASON_EPT_MISCONFIG,         "EPT_MISCONFIG" }, \
>  	{ EXIT_REASON_INVEPT,                "INVEPT" }, \
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index b133fc3d6a7d..0706e363c5e3 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -3342,6 +3342,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf)
>  			SECONDARY_EXEC_ENABLE_EPT |
>  			SECONDARY_EXEC_UNRESTRICTED_GUEST |
>  			SECONDARY_EXEC_PAUSE_LOOP_EXITING |
> +			SECONDARY_EXEC_DESC |
>  			SECONDARY_EXEC_RDTSCP |
>  			SECONDARY_EXEC_ENABLE_INVPCID |
>  			SECONDARY_EXEC_APIC_REGISTER_VIRT |
> @@ -3967,6 +3968,14 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>  		(to_vmx(vcpu)->rmode.vm86_active ?
>  		 KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON);
>
> +	if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
> +		vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
> +			      SECONDARY_EXEC_DESC);
> +		hw_cr4 &= ~X86_CR4_UMIP;
> +	} else
> +		vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
> +				SECONDARY_EXEC_DESC);
> +

Since the faults based on privilege level have priority over VM exits. 
So we don't need to enable/disable SECONDARY_EXEC_DESC dynamically. 
Instead, we can set it unconditionally.

>  	if (cr4 & X86_CR4_VMXE) {
>  		/*
>  		 * To use VMXON (and later other VMX instructions), a guest
> @@ -4913,6 +4922,11 @@ static u32 vmx_exec_control(struct vcpu_vmx *vmx)
>  static u32 vmx_secondary_exec_control(struct vcpu_vmx *vmx)
>  {
>  	u32 exec_control = vmcs_config.cpu_based_2nd_exec_ctrl;
> +
> +	/* SECONDARY_EXEC_DESC is enabled/disabled on writes to CR4.UMIP,
> +	 * in vmx_set_cr4.  */
> +	exec_control &= ~SECONDARY_EXEC_DESC;
> +
>  	if (!cpu_need_virtualize_apic_accesses(&vmx->vcpu))
>  		exec_control &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
>  	if (vmx->vpid == 0)
> @@ -5649,6 +5663,12 @@ static void handle_clts(struct kvm_vcpu *vcpu)
>  		vmx_set_cr0(vcpu, kvm_read_cr0_bits(vcpu, ~X86_CR0_TS));
>  }
>
> +static int handle_desc(struct kvm_vcpu *vcpu)
> +{
> +	WARN_ON(!(vcpu->arch.cr4 & X86_CR4_UMIP));

I think WARN_ON is too heavy since a malicious guest may trigger it always.

> +	return emulate_instruction(vcpu, 0) == EMULATE_DONE;
> +}
> +
>  static int handle_cr(struct kvm_vcpu *vcpu)
>  {
>  	unsigned long exit_qualification, val;
> @@ -7705,6 +7731,8 @@ static int (*const kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = {
>  	[EXIT_REASON_XSETBV]                  = handle_xsetbv,
>  	[EXIT_REASON_TASK_SWITCH]             = handle_task_switch,
>  	[EXIT_REASON_MCE_DURING_VMENTRY]      = handle_machine_check,
> +	[EXIT_REASON_GDTR_IDTR]		      = handle_desc,
> +	[EXIT_REASON_LDTR_TR]		      = handle_desc,
>  	[EXIT_REASON_EPT_VIOLATION]	      = handle_ept_violation,
>  	[EXIT_REASON_EPT_MISCONFIG]           = handle_ept_misconfig,
>  	[EXIT_REASON_PAUSE_INSTRUCTION]       = handle_pause,
> @@ -7972,6 +8000,8 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu)
>  		return nested_cpu_has(vmcs12, CPU_BASED_MOV_DR_EXITING);
>  	case EXIT_REASON_IO_INSTRUCTION:
>  		return nested_vmx_exit_handled_io(vcpu, vmcs12);
> +	case EXIT_REASON_GDTR_IDTR: case EXIT_REASON_LDTR_TR:
> +		return nested_cpu_has2(vmcs12, SECONDARY_EXEC_DESC);
>  	case EXIT_REASON_MSR_READ:
>  	case EXIT_REASON_MSR_WRITE:
>  		return nested_vmx_exit_handled_msr(vcpu, vmcs12, exit_reason);
> @@ -8597,7 +8627,8 @@ static bool vmx_xsaves_supported(void)
>
>  static bool vmx_umip_emulated(void)
>  {
> -	return false;
> +	return vmcs_config.cpu_based_2nd_exec_ctrl &
> +		SECONDARY_EXEC_DESC;
>  }
>
>  static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx)
> @@ -9173,7 +9204,8 @@ static void vmcs_set_secondary_exec_control(u32 new_ctl)
>  	u32 mask =
>  		SECONDARY_EXEC_SHADOW_VMCS |
>  		SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
> -		SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> +		SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
> +		SECONDARY_EXEC_DESC;
>
>  	u32 cur_ctl = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
>
>


-- 
Yang
Alibaba Cloud Computing

[toc] | [prev] | [next] | [standalone]

#1442259

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-07-13 11:40 +0200
Message-ID<rUoO5-17A-9@gated-at.bofh.it>
In reply to#1442255

On 13/07/2016 11:21, Yang Zhang wrote:
>>
>> +    if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
>> +        vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
>> +                  SECONDARY_EXEC_DESC);
>> +        hw_cr4 &= ~X86_CR4_UMIP;
>> +    } else
>> +        vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
>> +                SECONDARY_EXEC_DESC);
>> +
> 
> Since the faults based on privilege level have priority over VM exits.
> So we don't need to enable/disable SECONDARY_EXEC_DESC dynamically.
> Instead, we can set it unconditionally.

I'm setting it dynamically because it slows down LGDT, LLDT, LIDT and LTR.

Paolo

[toc] | [prev] | [next] | [standalone]

#1442278

FromYang Zhang <yang.zhang.wz@gmail.com>
Date2016-07-13 12:00 +0200
Message-ID<rUp7s-1hq-9@gated-at.bofh.it>
In reply to#1442259
On 2016/7/13 17:35, Paolo Bonzini wrote:
>
>
> On 13/07/2016 11:21, Yang Zhang wrote:
>>>
>>> +    if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
>>> +        vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
>>> +                  SECONDARY_EXEC_DESC);
>>> +        hw_cr4 &= ~X86_CR4_UMIP;
>>> +    } else
>>> +        vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
>>> +                SECONDARY_EXEC_DESC);
>>> +
>>
>> Since the faults based on privilege level have priority over VM exits.
>> So we don't need to enable/disable SECONDARY_EXEC_DESC dynamically.
>> Instead, we can set it unconditionally.
>
> I'm setting it dynamically because it slows down LGDT, LLDT, LIDT and LTR.

You are right. And SGDT, SIDT, SLDT, SMSW, STR also will be intercepted 
even in CPL 0 if we don't disable it.

-- 
Yang
Alibaba Cloud Computing

[toc] | [prev] | [next] | [standalone]

#1442263

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-07-13 11:40 +0200
Message-ID<rUoO6-17A-17@gated-at.bofh.it>
In reply to#1442255

On 13/07/2016 11:21, Yang Zhang wrote:
>>
>> +static int handle_desc(struct kvm_vcpu *vcpu)
>> +{
>> +    WARN_ON(!(vcpu->arch.cr4 & X86_CR4_UMIP));
> 
> I think WARN_ON is too heavy since a malicious guest may trigger it always.

I missed this---how so?  Setting the bit is under "if ((cr4 &
X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP))".

Paolo

[toc] | [prev] | [next] | [standalone]

#1442285

FromYang Zhang <yang.zhang.wz@gmail.com>
Date2016-07-13 12:10 +0200
Message-ID<rUph7-1FZ-5@gated-at.bofh.it>
In reply to#1442263
On 2016/7/13 17:35, Paolo Bonzini wrote:
>
>
> On 13/07/2016 11:21, Yang Zhang wrote:
>>>
>>> +static int handle_desc(struct kvm_vcpu *vcpu)
>>> +{
>>> +    WARN_ON(!(vcpu->arch.cr4 & X86_CR4_UMIP));
>>
>> I think WARN_ON is too heavy since a malicious guest may trigger it always.
>
> I missed this---how so?  Setting the bit is under "if ((cr4 &
> X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP))".

Sorry, I consider it under my previous suggestion(setting it 
unconditionally). :(

-- 
Yang
Alibaba Cloud Computing

[toc] | [prev] | [next] | [standalone]

#1442306

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-07-13 12:30 +0200
Message-ID<rUpAv-1Nt-65@gated-at.bofh.it>
In reply to#1442285

On 13/07/2016 12:02, Yang Zhang wrote:
> On 2016/7/13 17:35, Paolo Bonzini wrote:
>>
>>
>> On 13/07/2016 11:21, Yang Zhang wrote:
>>>>
>>>> +static int handle_desc(struct kvm_vcpu *vcpu)
>>>> +{
>>>> +    WARN_ON(!(vcpu->arch.cr4 & X86_CR4_UMIP));
>>>
>>> I think WARN_ON is too heavy since a malicious guest may trigger it
>>> always.
>>
>> I missed this---how so?  Setting the bit is under "if ((cr4 &
>> X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP))".
> 
> Sorry, I consider it under my previous suggestion(setting it
> unconditionally). :(

No problem, thanks for your interest!

Paolo

[toc] | [prev] | [next] | [standalone]

#1442828

FromRadim Krčmář <rkrcmar@redhat.com>
Date2016-07-13 22:40 +0200
Message-ID<rUz6N-83G-19@gated-at.bofh.it>
In reply to#1441678
2016-07-12 21:20+0200, Paolo Bonzini:
> UMIP (User-Mode Instruction Prevention) is a feature of future
> Intel processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT
> and SMSW from user-mode processes.
> 
> On Intel systems it's *almost* possible to emulate it; it slows
> down the instructions when they're executed in ring 0, but they
> are really never executed in practice.  The catch is that SMSW
> doesn't cause a vmexit, and hence SMSW will not fault.
> 
> When UMIP is enabled but not supported by the host, descriptor table
> exits are enabled, and the emulator takes care of injecting a #GP when
> any of SLDT, SGDT, STR, SIDT are encountered.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> @@ -3967,6 +3968,14 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>  		(to_vmx(vcpu)->rmode.vm86_active ?
>  		 KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON);
>  
> +	if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
> +		vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
> +			      SECONDARY_EXEC_DESC);

If UMIP support is not exposed in CPUID, we ought to #GP(0), because it
is a write to reserved bits.  It could also mean that the vm control is
not supported.

> +		hw_cr4 &= ~X86_CR4_UMIP;
> +	} else
> +		vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
> +				SECONDARY_EXEC_DESC);

I think we don't have to do anything when the CPU supports UMIP,

 if (!boot_cpu_has(X86_FEATURE_UMIP) {
   if ((cr4 & X86_CR4_UMIP)) { ... } else ...
 }

And we could then return true in vmx_umip_emulated() when
boot_cpu_has(X86_FEATURE_UMIP).
(Just for self-documentation, because occurrence of X86_FEATURE_UMIP is
 most likely a subset of SECONDARY_EXEC_DESC.)

> @@ -8597,7 +8627,8 @@ static bool vmx_xsaves_supported(void)
>  
>  static bool vmx_umip_emulated(void)
>  {
> -	return false;
> +	return vmcs_config.cpu_based_2nd_exec_ctrl &
> +		SECONDARY_EXEC_DESC;
>  }

[toc] | [prev] | [next] | [standalone]

#1443156

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-07-14 10:20 +0200
Message-ID<rUK2f-75j-65@gated-at.bofh.it>
In reply to#1442828

On 13/07/2016 22:30, Radim Krčmář wrote:
> 2016-07-12 21:20+0200, Paolo Bonzini:
>> UMIP (User-Mode Instruction Prevention) is a feature of future
>> Intel processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT
>> and SMSW from user-mode processes.
>>
>> On Intel systems it's *almost* possible to emulate it; it slows
>> down the instructions when they're executed in ring 0, but they
>> are really never executed in practice.  The catch is that SMSW
>> doesn't cause a vmexit, and hence SMSW will not fault.
>>
>> When UMIP is enabled but not supported by the host, descriptor table
>> exits are enabled, and the emulator takes care of injecting a #GP when
>> any of SLDT, SGDT, STR, SIDT are encountered.
>>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> @@ -3967,6 +3968,14 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>>  		(to_vmx(vcpu)->rmode.vm86_active ?
>>  		 KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON);
>>  
>> +	if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
>> +		vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
>> +			      SECONDARY_EXEC_DESC);
> 
> If UMIP support is not exposed in CPUID, we ought to #GP(0), because it
> is a write to reserved bits.  It could also mean that the vm control is
> not supported.

Yes, this is done in kvm_set_cr4:

        if (cr4 & CR4_RESERVED_BITS)
                return 1;
	...
        if (!guest_cpuid_has_umip(vcpu) && (cr4 & X86_CR4_UMIP))
                return 1;

>> +		hw_cr4 &= ~X86_CR4_UMIP;
>> +	} else
>> +		vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
>> +				SECONDARY_EXEC_DESC);
> 
> I think we don't have to do anything when the CPU supports UMIP,
> 
>  if (!boot_cpu_has(X86_FEATURE_UMIP) {
>    if ((cr4 & X86_CR4_UMIP)) { ... } else ...
>  }

Right.

> And we could then return true in vmx_umip_emulated() when
> boot_cpu_has(X86_FEATURE_UMIP).
> (Just for self-documentation, because occurrence of X86_FEATURE_UMIP is
>  most likely a subset of SECONDARY_EXEC_DESC.)

This is not necessary because this is how KVM computes
CPUID[EAX=7,EBX=0].ECX:

        unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0;
	...
        const u32 kvm_cpuid_7_0_ecx_x86_features = F(PKU) | F(UMIP);
	...
	// Mask userspace-provided value against supported features
	entry->ecx &= kvm_cpuid_7_0_ecx_x86_features;
	// Mask userspace-provided value against host features
	cpuid_mask(&entry->ecx, CPUID_7_ECX);
	// Finally add emulated features
	entry->ecx |= f_umip;

Paolo

>> @@ -8597,7 +8627,8 @@ static bool vmx_xsaves_supported(void)
>>  
>>  static bool vmx_umip_emulated(void)
>>  {
>> -	return false;
>> +	return vmcs_config.cpu_based_2nd_exec_ctrl &
>> +		SECONDARY_EXEC_DESC;
>>  }

[toc] | [prev] | [next] | [standalone]

#1443412

FromRadim Krčmář <rkrcmar@redhat.com>
Date2016-07-14 14:40 +0200
Message-ID<rUO5Q-1gA-17@gated-at.bofh.it>
In reply to#1443156
2016-07-14 10:09+0200, Paolo Bonzini:
> On 13/07/2016 22:30, Radim Krčmář wrote:
>> 2016-07-12 21:20+0200, Paolo Bonzini:
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> @@ -3967,6 +3968,14 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>>>  		(to_vmx(vcpu)->rmode.vm86_active ?
>>>  		 KVM_RMODE_VM_CR4_ALWAYS_ON : KVM_PMODE_VM_CR4_ALWAYS_ON);
>>>  
>>> +	if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
>>> +		vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
>>> +			      SECONDARY_EXEC_DESC);
>> 
>> If UMIP support is not exposed in CPUID, we ought to #GP(0), because it
>> is a write to reserved bits.  It could also mean that the vm control is
>> not supported.
> 
> Yes, this is done in kvm_set_cr4:
> 
>         if (cr4 & CR4_RESERVED_BITS)
>                 return 1;
> 	...
>         if (!guest_cpuid_has_umip(vcpu) && (cr4 & X86_CR4_UMIP))
>                 return 1;

Missed that,

>> And we could then return true in vmx_umip_emulated() when
>> boot_cpu_has(X86_FEATURE_UMIP).
>> (Just for self-documentation, because occurrence of X86_FEATURE_UMIP is
>>  most likely a subset of SECONDARY_EXEC_DESC.)
> 
> This is not necessary because this is how KVM computes
> CPUID[EAX=7,EBX=0].ECX:
> 
>         unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0;
> 	...
>         const u32 kvm_cpuid_7_0_ecx_x86_features = F(PKU) | F(UMIP);

and that too, I'm really sorry for the review.

> 	...
> 	// Mask userspace-provided value against supported features
> 	entry->ecx &= kvm_cpuid_7_0_ecx_x86_features;
> 	// Mask userspace-provided value against host features
> 	cpuid_mask(&entry->ecx, CPUID_7_ECX);
> 	// Finally add emulated features
> 	entry->ecx |= f_umip;

[toc] | [prev] | [next] | [standalone]

#1443430

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-07-14 15:00 +0200
Message-ID<rUOpb-1nZ-1@gated-at.bofh.it>
In reply to#1443412

On 14/07/2016 14:36, Radim Krčmář wrote:
>>> And we could then return true in vmx_umip_emulated() when
>>> boot_cpu_has(X86_FEATURE_UMIP).
>>> (Just for self-documentation, because occurrence of X86_FEATURE_UMIP is
>>>  most likely a subset of SECONDARY_EXEC_DESC.)
>>
>> This is not necessary because this is how KVM computes
>> CPUID[EAX=7,EBX=0].ECX:
>>
>>         unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0;
>> 	...
>>         const u32 kvm_cpuid_7_0_ecx_x86_features = F(PKU) | F(UMIP);
> 
> and that too, I'm really sorry for the review.

At least in the latter case, that says something about the code quality too.

Paolo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web