Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762397AbdLSLtJ (ORCPT ); Tue, 19 Dec 2017 06:49:09 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35669 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762375AbdLSLtD (ORCPT ); Tue, 19 Dec 2017 06:49:03 -0500 X-Google-Smtp-Source: ACJfBosB1DcqbPf719h1ch8OjIFmN58JBmH70vlaxWzmZmcXndgbLAn8x8GTlTyW+FjajA0Vm7fUeCqEzYw9A3a8bZM= MIME-Version: 1.0 In-Reply-To: <20171215164458.gyqzt2c5h3clpesc@gmail.com> References: <1036ed60-035c-70a0-0a5f-00efe8ebf4da@redhat.com> <20171215164458.gyqzt2c5h3clpesc@gmail.com> From: Dmitry Vyukov Date: Tue, 19 Dec 2017 12:48:41 +0100 Message-ID: Subject: Re: BUG: unable to handle kernel paging request in __switch_to To: Ingo Molnar Cc: Andy Lutomirski , Wanpeng Li , David Hildenbrand , Linus Torvalds , Thomas Gleixner , syzbot , Borislav Petkov , Dmitry Safonov , Peter Anvin , Linux Kernel Mailing List , Kyle Huey , Ingo Molnar , syzkaller-bugs@googlegroups.com, "the arch/x86 maintainers" , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , KVM list , "Lan, Tianyu" , James Mattson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3061 Lines: 81 On Fri, Dec 15, 2017 at 5:44 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> On Fri, Dec 15, 2017 at 2:02 AM, Dmitry Vyukov wrote: >> > On Fri, Dec 15, 2017 at 10:58 AM, Wanpeng Li wrote: >> >> 2017-12-15 17:51 GMT+08:00 David Hildenbrand : >> >>> >> >>>> int main() >> >>>> { >> >>>> int fd = open("/dev/kvm", 0x80102ul); >> >>>> int vm = ioctl(fd, KVM_CREATE_VM, 0); >> >>>> int cpu = ioctl(vm, KVM_CREATE_VCPU, 4); >> >>> >> >>> Not even a memory region :) So maybe the first memory access directly >> >>> triggers a fault? >> >>> >> >>>> ioctl(cpu, KVM_RUN, 0); >> >>>> return 0; >> >>>> } >> >>>> >> >>>> And, yes, this in fact triggers instant reboot of kernel (running in qemu). >> >>>> Am I missing something here? >> >>>> >> >>>> +kvm maintainers, you can see full thread here: >> >>>> https://groups.google.com/forum/#!topic/syzkaller-bugs/_oveOKGm3jw >> >> >> >> I didn't see any issue after running the test. >> > >> > Yes, it's strange. But I can reproduce it. There must be something >> > different in our setups. >> > Here is how to build exact same kernel: >> > https://groups.google.com/d/msg/syzkaller-bugs/_oveOKGm3jw/vc1tXvsbCgAJ >> > >> > Here is how I start qemu: >> > >> > qemu-system-x86_64 -hda wheezy.img -net >> > user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic -nographic -kernel >> > arch/x86/boot/bzImage -append "kvm-intel.nested=1 >> > kvm-intel.unrestricted_guest=1 kvm-intel.ept=1 >> > kvm-intel.flexpriority=1 kvm-intel.vpid=1 >> > kvm-intel.emulate_invalid_guest_state=1 kvm-intel.eptad=1 >> > kvm-intel.enable_shadow_vmcs=1 kvm-intel.pml=1 >> > kvm-intel.enable_apicv=1 console=ttyS0 root=/dev/sda >> > earlyprintk=serial slub_debug=UZ vsyscall=native rodata=n oops=panic >> > panic_on_warn=1 panic=86400" -enable-kvm -pidfile vm_pid -m 2G -smp 4 >> > -cpu host -usb -usbdevice mouse -usbdevice tablet -soundhw all >> > >> > The image is here: >> > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce >> > >> > Host cpu is Intel(R) Xeon(R) CPU E5-2690 v3 >> >> Looking more closely, you seem to be testing this: >> >> commit d127129e85a020879f334154300ddd3f7ec21c1e (HEAD, tag: next-20171129) >> Author: Stephen Rothwell >> Date: Wed Nov 29 14:09:56 2017 +1100 >> Add linux-next specific files for 20171129 >> >> which is almost certainly missing this fix: >> >> https://lkml.kernel.org/r/bc7296f4c8d86af71c31a17588c79d89c0890edc.1512109321.git.luto@kernel.org >> >> on account of the fix being sent the day after the tag. >> >> The symptoms you're seeing are definitely consistent with a screwed up >> TSS after VM exit. > > Note that this should all be fixed in WIP.x86/pti. > > If you have: > > 5ed1fcd523b9: x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss > > then you should be fine. Let's tell syzbot about the fix: #syz fix: x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss