Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1015897ybz; Wed, 22 Apr 2020 11:59:59 -0700 (PDT) X-Google-Smtp-Source: APiQypKw3plRDeQirYumGhrMONcO5Rwf4lpFO/MK5YzmxBuKy07dcsDKgmChmL29Lm0BlsOQkgll X-Received: by 2002:a05:6402:2d5:: with SMTP id b21mr32005edx.291.1587581998978; Wed, 22 Apr 2020 11:59:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587581998; cv=none; d=google.com; s=arc-20160816; b=v7J+f6Qx3/S6dCamSinD5bhh55IOSZB9Snw0c6+ZMezq3dLjf2igrHpE2zJfFsGPz2 5S7RvfLAZt7/W7oqGYmjwBmbSIvFTBjtPaZI4Y9J23xT1lfXOMsw5QB0A5n56wYERYDE /x+2hgB98fYRLv6P9r++/mYqUnR5k04QL8RO+3D7/+C5SjzdnXXPbESpC4y0HYZa4BqF Nmo+eprhoV+CZdYS5prbfCNFLQEnKPvR4DK/AmlZJAUOh1buu71s+CMgnkxijMyCRlfz DQXqM7rmbLDPLA1zoug7angD8U2FPlwjBhzMcYeS+yUvo2qSOUI1itLKjSYsZLUgKi+q Ujlw== 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=3sa/gVNaip+9XRbdoEuhfmV9mpmTLztLhq1CX0xqZKM=; b=utvCNOHMLPfzrCQNSSlZVIjccE49U8WLGa9zxC6lOH3RY6L2Wj/I1seBHh8IKuDa3p NWNTelMe3+F9F+IOQF0kYcP0tLVqQ9JucO6/37j65Hxwf0blRz67w6qWwZU6nHnjy0LB ESsyFhsq2QGoKMN3uROYdEq74tlMgxs0Pp9QTW0LfUGSBaGrj6zU7KjMCKsvDLWVmo1Z HzNGi53HJTrjr1iT6poQGqXKFe7Tnt3FkiOQA/KExV8dsRmXvUZohqlDVkcmQMoqPQQe HK44gesJoqXZrYo+oY7cWnTi9kA5RnupwLfsXWoXz6kIVfjzovJblijuSo3L6p3BVrGv EMbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TeTZHVtr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id c5si53765ejr.178.2020.04.22.11.59.28; Wed, 22 Apr 2020 11:59:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TeTZHVtr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1726777AbgDVS4E (ORCPT + 99 others); Wed, 22 Apr 2020 14:56:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726208AbgDVS4E (ORCPT ); Wed, 22 Apr 2020 14:56:04 -0400 Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EF66C03C1A9 for ; Wed, 22 Apr 2020 11:56:04 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id w3so1301002plz.5 for ; Wed, 22 Apr 2020 11:56:04 -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=3sa/gVNaip+9XRbdoEuhfmV9mpmTLztLhq1CX0xqZKM=; b=TeTZHVtryc/TNpZDkEHi8Lap8iCWQeAkNNt/EuK6exhX8Ba2jVVcA+bTbQcnJEr0df HX3BkrkG7XxP18JV0chyW5cvhKlzBfw1uD3ir1HuhEPwgY1NiKy6jxedoB+JOAZBH9CY 1zlHtkyCOlKm3Lxhb6wBA1DtYNVYUuH7SyT4HeoNl71o7u/TIbtCAXHs0EOAMdfu9Ljh 4lnUJJzKrdrxUaNaORwXM4rQTDm3sFB7k/LP3fZ6D/GeFO5PDSQ/Q3TSboJHODxkJkw+ SGjDEDsPK1YBKM0xZIQ/B0EKTw2gfFzM5jOJIcz3bip2lC33xt2FOdb28x85B9kWp60R bg9g== 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=3sa/gVNaip+9XRbdoEuhfmV9mpmTLztLhq1CX0xqZKM=; b=TGE+VQ3XkC0qZ6l5Ejrz5mLRTDNTMORZrqmp5nKHfgeQIhIdaNbzI0aZYt8WWGaDnH qELHMjRvxSyyOEnYHlK+a26OSCWYF3eeuGCxSCwd0A91cTGiq8cifEVZ4EYmnO1zLgia vKCTHGLNqAzfLaBhAUldv53Mh6l3fCNmQ+jdzOtgLpyRvKQ/oHUKud42cSR0szwj47BR yifJaVv8H0CSxROk0lU90eGVZmVuCxEKlWtyRIQhbvgRkXm+3zgB/+QgxTdMN0SC9nzP ZY8/3E1af5eoieWnOqK4djmscQ/F78dgvM4+veDglOvs8G8EQhHSSEhe4RtE3BqIWwsZ 3Ngw== X-Gm-Message-State: AGi0PubrlVvpxp6U462kLCGU6uIib6c0lHnYXWgFc4kdoVSrE49nD5b0 nXPwQ0NgNvuPUiusE4/9OBPBHMmgjoxKkJQSmgiJCA== X-Received: by 2002:a17:902:b20e:: with SMTP id t14mr69738plr.223.1587581763189; Wed, 22 Apr 2020 11:56:03 -0700 (PDT) MIME-Version: 1.0 References: <20200417075739.GA7322@zn.tnic> <20200417080726.GS2424@tucnak> <20200417084224.GB7322@zn.tnic> <20200417085859.GU2424@tucnak> <20200417090909.GC7322@zn.tnic> <20200417190607.GY2424@tucnak> <20200422102309.GA26846@zn.tnic> In-Reply-To: <20200422102309.GA26846@zn.tnic> From: Nick Desaulniers Date: Wed, 22 Apr 2020 11:55:50 -0700 Message-ID: Subject: Re: [PATCH v2] x86: fix early boot crash on gcc-10 To: Borislav Petkov Cc: Michael Matz , Jakub Jelinek , Sergei Trofimovich , LKML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , clang-built-linux , Kees Cook 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 Wed, Apr 22, 2020 at 3:23 AM Borislav Petkov wrote: > > Ok, > > let's try the simple and clean fix first. Nick, would that work on LLVM > too? > > And I hope this will remain working and the compiler won't jump over an > inline asm and go nuts. > > Thx. > > --- > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 3b9bf8c7e29d..06d2e16bedbb 100644 > --- a/arch/x86/kernel/smpboot.c > +++ b/arch/x86/kernel/smpboot.c > @@ -266,6 +266,13 @@ static void notrace start_secondary(void *unused) > > wmb(); > cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); > + > + /* > + * Prevent tail call to cpu_startup_entry() because the stack protector > + * guard has been changed in the middle of this function and must not be > + * checked before tail calling another function. Can you add by whom? It's not clear to me which function call in start_secondary modifies the stack protector guard. Another question. Do we not want a stack protector at all in this function? I'm not super familiar with how they work; do we not want them at all, or simply not to check the guard? But if we're not going to check it, I think __attribute__((no_stack_protector)) applied to start_secondary might be a more precise fix. Though the empty asm statement may be the most portable at this time, and with a well specified comment, I can live with it. > + */ > + asm (""); > } > > /** > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette -- Thanks, ~Nick Desaulniers