Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3035582ybc; Mon, 18 Nov 2019 08:31:42 -0800 (PST) X-Google-Smtp-Source: APXvYqx6m6k7j2QlblGRfx/OhJmxanVSzi/5+GFm17Qfl0lLsUGArP8GNcIRQt+vX1Zt/PIPaJmh X-Received: by 2002:a17:906:1cd8:: with SMTP id i24mr27623886ejh.149.1574094701967; Mon, 18 Nov 2019 08:31:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574094701; cv=none; d=google.com; s=arc-20160816; b=AabyEKlTKRYdfC5oZPy2Z2stlatlIjkRrZmWRaAydEIopcwzn5PiYnoJbzHokvH0fl QrNWGDZQXMxC5iy1VUhScYWzg5RrBMR3D0d378zZ92PVJ7waTT4zW5xRoYW9GgWSYV9F FCy7J1wRNy1hLvyzqERa+DKsdMXDYMs6U9M9bDq3JqWr8obvWiSjrhadm/MTtk8ZICBa D3w6G86GF01dlN85Vm+h9f+bMUoZQW5USNhM+3N1f5evTEADemgQstjl2P40+m0st1ni LAuxUx/hSJfax3OF4Ptyceno4gSLUByBtHwCc8D6gxCiGHv5QaN2JOsL9LNZKXfT27Cx owXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=EWpMW0feycxyW1VyPAp6s2ygtKt8fZ0jnVixWgUidTo=; b=YZsZd+0Py0BzKhXiK6ImMnJ8ZUKrEpbcrPZz2kj0/JvqM+2L6jQBp/dYjVUEBrI5iG h2x1Qkh0/W01XDSLu99Ftf82YpAK+gvTEyy5foGR/rNXMMSJhy/BZGqDfwFnZc36haMf BPLGrxFP7XUS2A0etraJG+5TkT5yPKnziD8D274X/bPnyH6lG6wsq8lxpUJzn6OmC0KE P9GrUWHAPyd4WtllDYOvEWYVVnwVrG/n26WQLgb1rJz6ZK+S5PH+XxouA9e7ZDGLu2oI CaNn/txye6Ky2+c7ReFH5My5A4l72QfY1vh/YxmlDEoewZqW54X3BcnIza2Y0s9vXH/a uQRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Pt744SvN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b27si11373579eje.95.2019.11.18.08.31.17; Mon, 18 Nov 2019 08:31:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Pt744SvN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726759AbfKRQ3z (ORCPT + 99 others); Mon, 18 Nov 2019 11:29:55 -0500 Received: from mail-qv1-f68.google.com ([209.85.219.68]:37958 "EHLO mail-qv1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726314AbfKRQ3z (ORCPT ); Mon, 18 Nov 2019 11:29:55 -0500 Received: by mail-qv1-f68.google.com with SMTP id q19so6782548qvs.5 for ; Mon, 18 Nov 2019 08:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EWpMW0feycxyW1VyPAp6s2ygtKt8fZ0jnVixWgUidTo=; b=Pt744SvNC62j6opLgPWAFSwqWlUntb6xcrd1f5fnDvNbHG1WGPOuFs7TkWF8poPM9u wQEr626LBed+U9NMcY06zOUyfJHkaxDQLnC6Sp2QwCsEPj6CSDf70MfcTo9GVQ/y1fG7 vXUkpZrGDuMjyH8j8LLYHeETAKAOzeK6ik62SAfPNuQB8Beg+t7MwBTtqKTklNrBmIlk 9+OXNWb+918b1LePPSrscR+Y66OxczYn/6Plb20ABke2OSFkPxM67jDrbRsVAHFJeQyN yYjxZvXvkEGsxRAO9HwnmXXgSuD4qua+Q2qFlJGpUvODVvbq96P2u/1Xp3Kr9NsqUWwO 832g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EWpMW0feycxyW1VyPAp6s2ygtKt8fZ0jnVixWgUidTo=; b=l7nj0rfqx1CD2qN5PWFozQoCxtSkXHB5KC+q6+3lu7Cio07FtWlrKKAifUoetS4X2A sYiXzo/EsN4koKdR6zM5EZFhpnmUBq8ThXlZptkNdw5QSAhe7Mze6BmfFn2ayOehFyhB Caf2809pgXzdRbmlqjGUqYkyzMD/Zy4DXEgh15TWTXergfq1jcu+iQ6NM7WRmaE74huZ EEYOEaWc+yDzrSLOV1PxRoa2jV/uRloc78h6mG2WJu08Zm3hnYVRu9vmDOioRUGA1XBv LtjuzwM5xLI7xMYrw55WWgEBao7Um5VkIFysDW4HX+aRXvniabYpYzqyW+uVYW77EgKK Gw6w== X-Gm-Message-State: APjAAAVyRBdzT39uruXqepwaVpf8EOomUMV3YVEZZHN/jbcbtGMnY7Hk 74nUAE4v0L88JXfsiABc0SCS0tYdgFP7VGpOqZB4Rg== X-Received: by 2002:a05:6214:8ee:: with SMTP id dr14mr27167149qvb.122.1574094593379; Mon, 18 Nov 2019 08:29:53 -0800 (PST) MIME-Version: 1.0 References: <20191115191728.87338-1-jannh@google.com> <20191115191728.87338-2-jannh@google.com> <20191118142144.GC6363@zn.tnic> In-Reply-To: From: Dmitry Vyukov Date: Mon, 18 Nov 2019 17:29:42 +0100 Message-ID: Subject: Re: [PATCH v2 2/3] x86/traps: Print non-canonical address on #GP To: Jann Horn Cc: Borislav Petkov , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "the arch/x86 maintainers" , Andrey Ryabinin , Alexander Potapenko , kasan-dev , LKML , Andrey Konovalov , Andy Lutomirski , Sean Christopherson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 18, 2019 at 5:20 PM 'Jann Horn' via kasan-dev wrote: > > On Mon, Nov 18, 2019 at 5:03 PM Dmitry Vyukov wrote: > > On Mon, Nov 18, 2019 at 3:21 PM Borislav Petkov wrote: > > > > > > On Fri, Nov 15, 2019 at 08:17:27PM +0100, Jann Horn wrote: > > > > dotraplinkage void > > > > do_general_protection(struct pt_regs *regs, long error_code) > > > > { > > > > @@ -547,8 +581,15 @@ do_general_protection(struct pt_regs *regs, long error_code) > > > > return; > > > > > > > > if (notify_die(DIE_GPF, desc, regs, error_code, > > > > - X86_TRAP_GP, SIGSEGV) != NOTIFY_STOP) > > > > - die(desc, regs, error_code); > > > > + X86_TRAP_GP, SIGSEGV) == NOTIFY_STOP) > > > > + return; > > > > + > > > > + if (error_code) > > > > + pr_alert("GPF is segment-related (see error code)\n"); > > > > + else > > > > + print_kernel_gp_address(regs); > > > > + > > > > + die(desc, regs, error_code); > > > > > > Right, this way, those messages appear before the main "general > > > protection ..." message: > > > > > > [ 2.434372] traps: probably dereferencing non-canonical address 0xdfff000000000001 > > > [ 2.442492] general protection fault: 0000 [#1] PREEMPT SMP > > > > > > Can we glue/merge them together? Or is this going to confuse tools too much: > > > > > > [ 2.542218] general protection fault while derefing a non-canonical address 0xdfff000000000001: 0000 [#1] PREEMPT SMP > > > > > > (and that sentence could be shorter too: > > > > > > "general protection fault for non-canonical address 0xdfff000000000001" > > > > > > looks ok to me too.) > > > > This exact form will confuse syzkaller crash parsing for Linux kernel: > > https://github.com/google/syzkaller/blob/1daed50ac33511e1a107228a9c3b80e5c4aebb5c/pkg/report/linux.go#L1347 > > It expects a "general protection fault:" line for these crashes. > > > > A graceful way to update kernel crash messages would be to add more > > tests with the new format here: > > https://github.com/google/syzkaller/tree/1daed50ac33511e1a107228a9c3b80e5c4aebb5c/pkg/report/testdata/linux/report > > Update parsing code. Roll out new version. Update all other testing > > systems that detect and parse kernel crashes. Then commit kernel > > changes. > > So for syzkaller, it'd be fine as long as we keep the colon there? > Something like: > > general protection fault: derefing non-canonical address > 0xdfff000000000001: 0000 [#1] PREEMPT SMP Probably. Tests help a lot to answer such questions ;) But presumably it should break parsing. > And it looks like the 0day test bot doesn't have any specific pattern > for #GP, it seems to just look for the panic triggered by > panic-on-oops as far as I can tell (oops=panic in lkp-exec/qemu, no > "general protection fault" in etc/dmesg-kill-pattern). > > > An unfortunate consequence of offloading testing to third-party systems... > > And of not having a standard way to signal "this line starts something > that should be reported as a bug"? Maybe as a longer-term idea, it'd > help to have some sort of extra prefix byte that the kernel can print > to say "here comes a bug report, first line should be the subject", or > something like that, similar to how we have loglevels... This would be great. Also a way to denote crash end. However we have lots of special logic for subjects, not sure if kernel could provide good subject: https://github.com/google/syzkaller/blob/1daed50ac33511e1a107228a9c3b80e5c4aebb5c/pkg/report/linux.go#L537-L1588 Probably it could, but it won't be completely trivial. E.g. if there is a stall inside of a timer function, it should give the name of the actual timer callback as identity ("stall in timer_subsystem_foo"). Or for syscalls we use more disambiguation b/c "in sys_ioclt" is not much different than saying "there is a bug in kernel" :)