Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2903103ybh; Mon, 16 Mar 2020 11:56:06 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuyMiMxLcieOEYWCtiklXtHgZ+lExYJsjBN/cCNIHQcCW99WXry+dnfSi2EkvYTUwIQm+K7 X-Received: by 2002:a9d:5ad:: with SMTP id 42mr558093otd.231.1584384966689; Mon, 16 Mar 2020 11:56:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584384966; cv=none; d=google.com; s=arc-20160816; b=p8KPSnwfkhjMjDZidWyaSFRal/FMPxYyjnqJiPoWhQ9fxp3UlsQrU2pUjt9npEamrJ Nu9uns9PPW4kZ+Htoqr+2sSKW/0qm81X1q0NT3mVSJrHXRjcn0WkWj7v90J0CRPaDxr0 M/i/S/WCvOwOEsJNs4BNda+Occd9Zwzw54nHFcPmYmYU2Rw6j6MHHIznGQvjwyHAvs46 8sFwOrZwCeVdrhw31Y+L0PYoxB6PlgSxhIQtvV8GM1aY7zisswLpvYDfxEX4XwKUwcI6 yfthArEEC+gKph+5d+nIu74hBSae6toVr9Sxd31yNNlq6ab+fdRtcQClvUtv3OnlzU+v wU2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date:from:dkim-signature; bh=j32gmo/PWyKSH2KKl33eo3+SCvi6lrdhWIC2GDs4hzo=; b=T/Ls+1/wESHBZx1nqDPvCYilvLFyksczUsdUAX1WeU8C3gbKrBGiBD5cbOpWCqibPj +zS5Fr3B+5Y5gd/f0DqEEOnuVgZo/PWnYAd/qy32uzk2tLT8mAhelkN8aMSSIqFLwa3b kbfoK/WlVo1wQQ9hTFTesEGVnCVSwak2E9c1LioRUUaj6H2fjlPPDRizFzjxNMviSlPc /RHR9y5J8Mzb+imt/EyXcAC8rMAvyTdUma3bKMHCUWJgmjxbrLtOESok6hTPjn27JSRT J982Sq66TGUvTwxgfZQ5+IZZ5YAdURmr2juMVNMffzpcpUlHXVLVbj32CFjSzmEm0duT yB7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ceDaX64L; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d21si343139otq.72.2020.03.16.11.55.54; Mon, 16 Mar 2020 11:56:06 -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=fail header.i=@gmail.com header.s=20161025 header.b=ceDaX64L; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732375AbgCPSyZ (ORCPT + 99 others); Mon, 16 Mar 2020 14:54:25 -0400 Received: from mail-qk1-f195.google.com ([209.85.222.195]:44688 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732298AbgCPSyY (ORCPT ); Mon, 16 Mar 2020 14:54:24 -0400 Received: by mail-qk1-f195.google.com with SMTP id j4so11560981qkc.11 for ; Mon, 16 Mar 2020 11:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=j32gmo/PWyKSH2KKl33eo3+SCvi6lrdhWIC2GDs4hzo=; b=ceDaX64LDB5mV76tG8Bfals1ox4n3w7v0y7LV6OXFe9M/JiYK9sujkHWz9OmhJxnYn hYPrupyZqumt9QjZsOnn9N8YFbwAGhIbs0U+uuDnGHwzmUrCtX471/atMrDkGA0XomNL GCU7E48vn+AEVU8KyP9so9W6hJQ8Idf2svmRw6eFz45mKsWurYtCxDHuFVNMy2+6YFKO o7e341biClIFOGiTO0/g1cVuXBgxIzSEIqd2Py2b2iQ9Uc4wP2a6hCyRLGy1ufYIvRVu y+9do1eQ0MPGGMCgJOpzMPYv61AVi/ntYbvnPPiZu/cOU55uk1f1FqsvT0PbY/ZAFyp1 yJkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=j32gmo/PWyKSH2KKl33eo3+SCvi6lrdhWIC2GDs4hzo=; b=KOLk2J891fseUg/Ys8QrFTdDr9yMFJfbjGevOOKLU+a6ra20+AY3M/legZzRzffi12 EvddT2jx7/76B60Pm6QSuA/A2vAAywo8L8hFXQPltXEdcz+9hUSQU4PJSHv5VzrdxIoL xso8D7MIiqfX/2MszYYmGnMAfrUHI+kNDmrUeHBWZpZavQtvgvT1DAO0D6CKlA9ZduGb iSPp3fCDLJTNfPhO1UtJy8fDPEwOELtbareA6Tz4ARonQC9Oez6lojaoK94b0zXSCv1g eae+MVgLDtDO/RSw2R9I1rwwLauUzxoIqSLE0iw56h1rzCUkbqOtrfhTP0OSnQJ9Wqsu j1Nw== X-Gm-Message-State: ANhLgQ3NRRI9RdBt5DqvVUsCxwWRPoSsiS5UCSaSJs219I/26Q/bKX4W 2CRe7gE7/4huGZQz2gj61to= X-Received: by 2002:a37:b944:: with SMTP id j65mr1154498qkf.374.1584384863306; Mon, 16 Mar 2020 11:54:23 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id w16sm334727qkw.37.2020.03.16.11.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2020 11:54:22 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Mon, 16 Mar 2020 14:54:21 -0400 To: Arvind Sankar Cc: Borislav Petkov , Peter Zijlstra , Jakub Jelinek , Sergei Trofimovich , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , x86@kernel.org Subject: Re: [PATCH] x86: fix early boot crash on gcc-10 Message-ID: <20200316185418.GA372474@rani.riverdale.lan> References: <20200314164451.346497-1-slyfox@gentoo.org> <20200316130414.GC12561@hirez.programming.kicks-ass.net> <20200316132648.GM2156@tucnak> <20200316134234.GE12561@hirez.programming.kicks-ass.net> <20200316175450.GO26126@zn.tnic> <20200316181957.GA348193@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200316181957.GA348193@rani.riverdale.lan> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 16, 2020 at 02:20:00PM -0400, Arvind Sankar wrote: > On Mon, Mar 16, 2020 at 06:54:50PM +0100, Borislav Petkov wrote: > > On Mon, Mar 16, 2020 at 02:42:34PM +0100, Peter Zijlstra wrote: > > > Right I know, I looked for it recently :/ But since this is new in 10 > > > and 10 isn't released yet, I figured someone can add the attribute > > > before it does get released. > > > > Yes, that would be a good solution. > > > > I looked at what happens briefly after building gcc10 from git and IINM, > > the function in question - start_secondary() - already gets the stack > > canary asm glue added so it checks for a stack canary. > > > > However, the stack canary value itself gets set later in that same > > function: > > > > /* to prevent fake stack check failure in clock setup */ > > boot_init_stack_canary(); > > > > so the asm glue which checks for it would need to reload the newly > > computed canary value (it is 0 before we compute it and thus the > > mismatch). > > > > So having a way to state "do not add stack canary checking to this > > particular function" would be optimal. And since you already have the > > "stack_protect" function attribute I figure adding a "no_stack_protect" > > one should be easy... > > > > > > Or of course you could add noinline attribute to whatever got inlined > > > > and contains some array or addressable variable that whatever > > > > -fstack-protector* mode kernel uses triggers it. With -fstack-protector-all > > > > it would never work even in the past I believe. > > > > > > I don't think the kernel supports -fstack-protector-all, but I could be > > > mistaken. > > > > The other thing I was thinking was to carve out only that function into > > a separate compilation unit and disable stack protector only for it. > > > > All IMHO of course. > > > > Thx. > > > > -- > > Regards/Gruss, > > Boris. > > > > https://people.kernel.org/tglx/notes-about-netiquette > > With STACKPROTECTOR_STRONG, gcc9 (at least gentoo's version, not sure if > they have some patches that affect it) already adds stack canary into > start_secondary. Not sure why it doesn't panic already with gcc9? > > 00000000000008f0 : > 8f0: 53 push %rbx > 8f1: 48 83 ec 10 sub $0x10,%rsp > 8f5: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax > 8fc: 00 00 > 8fe: 48 89 44 24 08 mov %rax,0x8(%rsp) > 903: 31 c0 xor %eax,%eax > ... > a2e: e8 00 00 00 00 callq a33 > a2f: R_X86_64_PLT32 cpu_startup_entry-0x4 > a33: 48 8b 44 24 08 mov 0x8(%rsp),%rax > a38: 65 48 33 04 25 28 00 xor %gs:0x28,%rax > a3f: 00 00 > a41: 75 12 jne a55 > a43: 48 83 c4 10 add $0x10,%rsp > a47: 5b pop %rbx > a48: c3 retq > a49: 0f 01 1d 00 00 00 00 lidt 0x0(%rip) # a50 > a4c: R_X86_64_PC32 debug_idt_descr-0x4 > a50: e9 cb fe ff ff jmpq 920 > a55: e8 00 00 00 00 callq a5a > a56: R_X86_64_PLT32 __stack_chk_fail-0x4 Wait a sec, this function calls cpu_startup_entry as the last thing it does, which should never return, and hence the stack canary value should never get checked. How does the canary get checked with the gcc10 code? boot_init_stack_canary depends on working if called from functions that don't return. If that doesn't work with gcc10, we need to disable stack protector for the other callpoints too -- start_kernel in init/main.c and cpu_bringup_and_idle in arch/x86/xen/smp_pv.c. /* * Initialize the stackprotector canary value. * * NOTE: this must only be called from functions that never return, * and it must always be inlined. */ static __always_inline void boot_init_stack_canary(void)