| Message ID | 20170322155354.18436-1-david@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2017-03-22 16:53+0100, David Hildenbrand: > 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: stable@vger.kernel.org # 4.2+ > Reported-by: Dmitry Vyukov <dvyukov@google.com> > Signed-off-by: David Hildenbrand <david@redhat.com> > --- > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 1faf620..7d0ec1b 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -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. > + (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 >
On Wed, Mar 22, 2017 at 5:49 PM, Radim Krčmář <rkrcmar@redhat.com> wrote: > 2017-03-22 16:53+0100, David Hildenbrand: >> 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: stable@vger.kernel.org # 4.2+ >> Reported-by: Dmitry Vyukov <dvyukov@google.com> >> Signed-off-by: David Hildenbrand <david@redhat.com> >> --- >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index 1faf620..7d0ec1b 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -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. > >> + (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
> 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 > 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.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1faf620..7d0ec1b 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -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);
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: stable@vger.kernel.org # 4.2+ Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: David Hildenbrand <david@redhat.com> --- arch/x86/kvm/x86.c | 6 ++++++ 1 file changed, 6 insertions(+)