Skip to contentSkip to conversation

KVM: x86: fix illegal MP_STATE when in/entering SMM

PATCH In review David Hildenbrand 3 participants 4 messages Mar 22, 2017 – Mar 23, 2017

Subsystems (4)
Stable branch x86 KVM KVM x86
lore
Share & tools
lore

David Hildenbrand

author
#0 lore raw

PATCH 1/1 KVM: x86: fix illegal MP_STATE when in/entering SMM

If we already entered/are about to enter SMM, don't allow switching to INIT/SIPI_RECEIVED, otherwise the next call to kvm_apic_accept_events() will report a warning.

Fixes cd7764fe9f73 ("KVM: x86: latch INITs while in system management mode")
Cc [email protected] # 4.2+
Reported-by Dmitry Vyukov <[email protected]>
Signed-off-by David Hildenbrand <[email protected]>
---
 arch/x86/kvm/x86.c | 6 ++++++
 1 file changed, 6 insertions(+)
arch/x86/kvm/x86.c +6 -0
index 1faf620..7d0ec1b 100644
@@ -7355,6 +7355,12 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
 	    mp_state->mp_state != KVM_MP_STATE_RUNNABLE)
 		return -EINVAL;
 
+	/* INITs are latched while in SMM */
+	if ((is_smm(vcpu) || vcpu->arch.smi_pending) &&
+	    (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED ||
+	     mp_state->mp_state == KVM_MP_STATE_INIT_RECEIVED))
+		return -EINVAL;
+
 	if (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED) {
 		vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED;
 		set_bit(KVM_APIC_SIPI, &vcpu->arch.apic->pending_events);
Signature · 1 line
2.9.3
#1 lore raw

2017-03-22 16:53+0100, David Hildenbrand:

Quoted 14 lines

If we already entered/are about to enter SMM, don't allow switching to INIT/SIPI_RECEIVED, otherwise the next call to kvm_apic_accept_events() will report a warning.

Fixes cd7764fe9f73 ("KVM: x86: latch INITs while in system management mode")
Cc [email protected] # 4.2+
Reported-by Dmitry Vyukov <[email protected]>
Signed-off-by David Hildenbrand <[email protected]>

---

arch/x86/kvm/x86.c +0 -0
index 1faf620..7d0ec1b 100644

arch/x86/kvm/x86.c int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu, · line 7359

Quoted 5 lines
arch/x86/kvm/x86.c +2 -0
@@ -7355,6 +7355,12 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
 	    mp_state->mp_state != KVM_MP_STATE_RUNNABLE)
 		return -EINVAL;
 
+	/* INITs are latched while in SMM */
+	if ((is_smm(vcpu) || vcpu->arch.smi_pending) &&

I think that userspace can still set the mpstate first and then enter SMM with KVM_SET_VCPU_EVENTS, which would result in the same warning ... Don't we need a similar check in kvm_vcpu_ioctl_x86_set_vcpu_events()?

Thanks.

Quoted 10 lines
arch/x86/kvm/x86.c +4 -0
+	    (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED ||
+	     mp_state->mp_state == KVM_MP_STATE_INIT_RECEIVED))
+		return -EINVAL;
+
 	if (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED) {
 		vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED;
 		set_bit(KVM_APIC_SIPI, &vcpu->arch.apic->pending_events);
Signature · 1 line
2.9.3
#2 lore raw
Quoted 18 lines · Radim Krčmář

2017-03-22 16:53+0100, David Hildenbrand:

Quoted 17 lines

If we already entered/are about to enter SMM, don't allow switching to INIT/SIPI_RECEIVED, otherwise the next call to kvm_apic_accept_events() will report a warning.

Fixes cd7764fe9f73 ("KVM: x86: latch INITs while in system management mode")
Cc [email protected] # 4.2+
Reported-by Dmitry Vyukov <[email protected]>
Signed-off-by David Hildenbrand <[email protected]>

---

arch/x86/kvm/x86.c +0 -0
index 1faf620..7d0ec1b 100644
@@ -7355,6 +7355,12 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
          mp_state->mp_state != KVM_MP_STATE_RUNNABLE)
              return -EINVAL;
Quoted 19 lines

arch/x86/kvm/x86.c int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu, · line 7359

Quoted 2 lines
arch/x86/kvm/x86.c +2 -0
+     /* INITs are latched while in SMM */
+     if ((is_smm(vcpu) || vcpu->arch.smi_pending) &&

I think that userspace can still set the mpstate first and then enter SMM with KVM_SET_VCPU_EVENTS, which would result in the same warning ... Don't we need a similar check in kvm_vcpu_ioctl_x86_set_vcpu_events()?

Thanks.

Quoted 10 lines
arch/x86/kvm/x86.c +4 -1
+         (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED ||
+          mp_state->mp_state == KVM_MP_STATE_INIT_RECEIVED))
+             return -EINVAL;
+
      if (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED) {
              vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED;
              set_bit(KVM_APIC_SIPI, &vcpu->arch.apic->pending_events);
--

2.9.3

This program still triggers the warning in kvm_apic_accept_events with the patch applied (on top of 093b995e3b55a0ae0670226ddfcb05bfbf0099ae):

https://gist.githubusercontent.com/dvyukov/2a39303347aa417aea2afd9fd99b7086/raw/09693aa7ed78d22b23948c726767f540b2276a99/gistfile1.txt

------------[ cut here ]------------
WARNING: CPU: 3 PID: 2964 at arch/x86/kvm/lapic.c:2461
kvm_apic_accept_events+0x46c/0x550 arch/x86/kvm/lapic.c:2461
CPU: 3 PID: 2964 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
 kvm_apic_accept_events+0x46c/0x550 arch/x86/kvm/lapic.c:2461
 vcpu_block arch/x86/kvm/x86.c:7010 [inline]
 vcpu_run arch/x86/kvm/x86.c:7048 [inline]
 kvm_arch_vcpu_ioctl_run+0xefc/0x59e0 arch/x86/kvm/x86.c:7207
 kvm_vcpu_ioctl+0x627/0x1100 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2573
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x447109
RSP: 002b:00007ffcb458a038 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000447109
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
R13: 00000000004073f0 R14: 0000000000407480 R15: 0000000000000000
author
#3 lore raw
Quoted 27 lines

This program still triggers the warning in kvm_apic_accept_events with the patch applied (on top of 093b995e3b55a0ae0670226ddfcb05bfbf0099ae):

https://gist.githubusercontent.com/dvyukov/2a39303347aa417aea2afd9fd99b7086/raw/09693aa7ed78d22b23948c726767f540b2276a99/gistfile1.txt

------------[ cut here ]------------
WARNING: CPU: 3 PID: 2964 at arch/x86/kvm/lapic.c:2461
kvm_apic_accept_events+0x46c/0x550 arch/x86/kvm/lapic.c:2461
CPU: 3 PID: 2964 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
 kvm_apic_accept_events+0x46c/0x550 arch/x86/kvm/lapic.c:2461
 vcpu_block arch/x86/kvm/x86.c:7010 [inline]
 vcpu_run arch/x86/kvm/x86.c:7048 [inline]
 kvm_arch_vcpu_ioctl_run+0xefc/0x59e0 arch/x86/kvm/x86.c:7207
 kvm_vcpu_ioctl+0x627/0x1100 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2573
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
Quoted 9 lines
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x447109
RSP: 002b:00007ffcb458a038 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000447109
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
R13: 00000000004073f0 R14: 0000000000407480 R15: 0000000000000000

I think we're seeing what Radim describes. So this is now a different call order.

The VCPU is set to KVM_MP_STATE_SIPI_RECEIVED (which results in KVM_MP_STATE_INIT_RECEIVED). Then, KVM_SET_VCPU_EVENTS
is set with KVM_VCPUEVENT_VALID_SMM | KVM_VCPUEVENT_VALID_NMI_PENDING, enabling SMM.

Calling kvm_apic_accept_events() then will result in a warning on the next VCPU run.

So the right thing is indeed adding an additional checks for KVM_SET_VCPU_EVENTS.

Signature · 3 lines
Thanks,

David