Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3974434ybb; Mon, 23 Mar 2020 11:08:08 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuB4c/fOw9lI8YHD08lx/r2J3kLCR2oWU7gja2wLyuUVwxtBrgYpNsnXQfEM8K/Ax1ZKcWM X-Received: by 2002:aca:3c56:: with SMTP id j83mr493862oia.52.1584986888144; Mon, 23 Mar 2020 11:08:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584986888; cv=none; d=google.com; s=arc-20160816; b=YsA7bAujTWirMmWjDlRkP1t6WCTK+3CNxHEGhWDyZ6ihwsITuZhb+TQTtEAqo/2wDl 7gKrWM2x+gckPDCK5jyE+ZeIT7OENwhO1WXKeUjzTlG33feJ15aRZkPw2/1PQ1EXU9Dw bkjC1RTp1wodvwvOTmPyXjozO1/o1gKERECUUTIf9JGjiY5StzKHmj7hxFofOdrjKiXx kGghIXJBSI4I9qszb+ORkZgl7LD7vczO8wNg7dF1Q38m3r0KGICp7aPoMsPaoWzTojF2 GfLZkTB8NHWUlYJZaXAgMPsp8eNn7+SDtud850caxW/Z0O4FCCay9CnvbeUIeB53wxVi tPnA== 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=hPUm/HhpONACSgj8NcmzE9a98krdtrzc27JDL5LBNKQ=; b=ZLOMKFZxHnIEdh71s556wC5I6xRr5URWdjMBiSqh4W5nM/YNDYOtdRsGjau9jip4rt 7IC9kEwJPdRry8a179PtC0pmHlgxpCZypq467RZIr9IAIFiqYS+nFlT8KTj0Q3z8gXjg 2LPJV3Dync+AR1W6eriCr6Y9Ohl/nDYgC2kCO3U4u2AHZumyiTF+x0ve7TY1zk7bQEqN GDnKurak1kkC/XLYwa907s+oxzuxn+2o1i+OFLKZ3rsloOryXt8fXN3Id5q3mdZTV9y7 4VQC6J0yWpsaDskCp9z6piquqeZhkTwgA5AXBcyCZiTWLnJVt8vjSEUg7jGLMOrF9K7o je1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=nTKGbJ64; 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 o18si8211950otk.80.2020.03.23.11.07.44; Mon, 23 Mar 2020 11:08:08 -0700 (PDT) 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=nTKGbJ64; 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 S1727697AbgCWSGv (ORCPT + 99 others); Mon, 23 Mar 2020 14:06:51 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:37272 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726991AbgCWSGv (ORCPT ); Mon, 23 Mar 2020 14:06:51 -0400 Received: by mail-wr1-f66.google.com with SMTP id w10so18316022wrm.4 for ; Mon, 23 Mar 2020 11:06:49 -0700 (PDT) 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=hPUm/HhpONACSgj8NcmzE9a98krdtrzc27JDL5LBNKQ=; b=nTKGbJ64Trr4thrThDxbIV2WGfup7R/kt56W8gtCc0GJQFu62G5jb8ufTMvwPcS3H+ uy7vPLpawyjtkoXkUf9FhUHOQSNUUYAIWgHq6iw+CMOWL1fO92pCVR5dCbzjvoYRKtA9 n4NXerLYtcyV4+0h4gfi0brs+dFhYIEGDuxe9OBqtVflmCd+trcADnuBg7/jnAxfxlFW 0D22pmxbRULBKGFWKFWB+f1u9iD6uIBGt3QYoiaTLyxDxZC9LUD0o+Oy5uP6AtG0zFuc qjKSW+Pry3/I6djMz2hqTEnQM4ymDQ3HIYyI0HVI+xZfLvbOEFB9LjGrB9AA7kX8GclZ eVoQ== 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=hPUm/HhpONACSgj8NcmzE9a98krdtrzc27JDL5LBNKQ=; b=iy+ZZsJWTXPqQuXn1GuSd7E+aM6av6h2ff8Mir/uD1eG3aKOPtl73dAM+EL7ed+wd5 gS9UW4FCCuwLzU8uRGS1usu08QXkOnZ83MdmvQTWERrf+d8uN6wOuLsy1tGJcz1hx+Zv NeoqiDYnLsCfQGGUvJ76krksQBeuKdTrKKQx1ileFhHIvthT7Q2MvFqo1VJ6eOcyWPtI 43QjQJUVe4KZ0ab7iGLr6V3g4/xcoy259UsjnGgfj//HHxyFkvZ65a6LVSH2iFMIMPG8 AnItXecDTqZ2lX8Fs54ucrxhoya044hWjFlZ+9LNvbP9Zr5O2WbxnpzsfvMcuCtD3okm ILKA== X-Gm-Message-State: ANhLgQ1M290OnCNFtKXLITs9e8GheHwRnistiUmmu3v/UrnU5nsJL4V6 MJROLe1NxLWzxLbjf+e1jvmyF01gI+da8aHzXApT5w== X-Received: by 2002:a05:6000:100f:: with SMTP id a15mr29739901wrx.382.1584986808806; Mon, 23 Mar 2020 11:06:48 -0700 (PDT) MIME-Version: 1.0 References: <000000000000277a0405a16bd5c9@google.com> <5058aabe-f32d-b8ef-57ed-f9c0206304c5@redhat.com> <20200323163925.GP28711@linux.intel.com> In-Reply-To: From: Alexander Potapenko Date: Mon, 23 Mar 2020 19:06:37 +0100 Message-ID: Subject: Re: BUG: unable to handle kernel NULL pointer dereference in handle_external_interrupt_irqoff To: Nick Desaulniers Cc: Dmitry Vyukov , Paolo Bonzini , syzbot , clang-built-linux , Borislav Petkov , "H. Peter Anvin" , Jim Mattson , Joerg Roedel , KVM list , LKML , Ingo Molnar , syzkaller-bugs , Thomas Gleixner , Vitaly Kuznetsov , Wanpeng Li , "the arch/x86 maintainers" , 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, Mar 23, 2020 at 6:55 PM Alexander Potapenko wrote: > > I've reduced the faulty test case to the following code: > > ================================= > a; > long b; > register unsigned long current_stack_pointer asm("rsp"); > handle_external_interrupt_irqoff() { > asm("and $0xfffffffffffffff0, %%rsp\n\tpush $%c[ss]\n\tpush " > "%[sp]\n\tpushf\n\tpushq $%c[cs]\n\tcall *%[thunk_target]\n" > : [ sp ] "=&r"(b), "+r" (current_stack_pointer) > : [ thunk_target ] "rm"(a), [ ss ] "i"(3 * 8), [ cs ] "i"(2 * 8) ); > } > ================================= > (in fact creduce even throws away current_stack_pointer, but we > probably want to keep it to prove the point). > > Clang generates the following code for it: > > $ clang vmx.i -O2 -c -w -o vmx.o > $ objdump -d vmx.o > ... > 0000000000000000 : > 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 > > 6: 89 44 24 fc mov %eax,-0x4(%rsp) > a: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp > e: 6a 18 pushq $0x18 > 10: 50 push %rax > 11: 9c pushfq > 12: 6a 10 pushq $0x10 > 14: ff 54 24 fc callq *-0x4(%rsp) > 18: 48 89 05 00 00 00 00 mov %rax,0x0(%rip) # 1f > > 1f: c3 retq > > The question is whether using current_stack_pointer as an output is > actually a valid way to tell the compiler it should not clobber RSP. > Intuitively it is, but explicitly adding RSP to the clobber list > sounds a bit more bulletproof. Ok, I am wrong: according to https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html it's incorrect to list RSP in the clobber list.