Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753349AbdLNV17 (ORCPT ); Thu, 14 Dec 2017 16:27:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:34510 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752154AbdLNV16 (ORCPT ); Thu, 14 Dec 2017 16:27:58 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D68AB219AD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: ACJfBovOzfWyg83wyLRroXvQ3gqD3HsB7DDELXEGxmDd/t+mc8Xt1YGTOlEQa26aKKbrsZnB/QGPMHQNhR25Hb0pUvI= MIME-Version: 1.0 In-Reply-To: References: <001a1145e8548cbd3d055f73374f@google.com> From: Andy Lutomirski Date: Thu, 14 Dec 2017 13:27:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: BUG: unable to handle kernel paging request in __switch_to To: Linus Torvalds Cc: Andy Lutomirski , 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" 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: 2586 Lines: 59 On Thu, Dec 14, 2017 at 11:28 AM, Linus Torvalds wrote: > On Thu, Dec 14, 2017 at 10:54 AM, Andy Lutomirski wrote: >> >> 2. It actually tries to handle the breakpoint. A breakpoint is a >> benign exception, so any exception encountered while delivering it >> would result in serial delivery. > > I don't think that's the case. "int3" is entirely synchronous, and > doesn't have the same odd issues as a breakpoint trap (which honors RF > etc). It's literally just a one-byte shorthand for "int $3". > The SDM says precisely the same thing about INT N, so, whichever way you dice it, int3 is a benign exception. > There should be no serial delivery, although obviously if it's a trap > gate (as opposed to an interrupt gate), you can get a normal external > interrupt on the first instruction of the exception handler. > > But that's not what the oops says: it says it happens on the "int3" instruction. > > Now, it is possible that the "int3" was written _after_ the CPU took a > real page fault on the original instruction, and that the original > instruction actually caused a perfectly normal page fault, and then we > just report the "int3" because another CPU overwrote the instruction > after the original instruction had already trapped. > > But that makes very little sense either. I really do think it's the > "int3" itself that causes the page fault due to some IDT/GDT change. > Because that would actually make sense considering what has changed in > the tree that Thomas is running. I still have trouble figuring what IDT or GDT error would cause a page fault and not a double-fault or triple-fault. So I like my bogus-IST-in-the-TSS theory more, even if I have no idea how it would happen. Entry stack underflow? Overflow of whatever is mapped just above the TSS in that kernel? Some kind of fuckup where ioperm() overwrote the IST? (I tested that, but who knows? This is a fuzz test, after all.) 0xfffffffffffffff8 is *exactly* where the fault would be if the microcoded push of SS faulted if the IST contained zeros. Hmm. There is another way that could happen. If the IDT ended up with the wrong IST entry, we could get the same failure. But I don't see how that would happen either. Maybe it's the bloody debug_idt thing blowing up? > > Plus I think the instruction that gets overwritten is just a 5-byte > nop isn't it? So it really shouldn't take a fault without the "int3" > overwriting. Unless it was being overwritten the other way and the oops hit while tracing was being turned *off*. --Andy