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(+)
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);
--
2.9.3
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: [email protected] # 4.2+
> Reported-by: Dmitry Vyukov <[email protected]>
> Signed-off-by: David Hildenbrand <[email protected]>
> ---
> 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ář <[email protected]> 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: [email protected] # 4.2+
>> Reported-by: Dmitry Vyukov <[email protected]>
>> Signed-off-by: David Hildenbrand <[email protected]>
>> ---
>> 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.
--
Thanks,
David