Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp967913ybz; Sat, 25 Apr 2020 08:08:49 -0700 (PDT) X-Google-Smtp-Source: APiQypKHSQWJ0mRFuOLdozUdXdu6HDSAWzyxjyrz0nW4dX+Kirkpxs2iq3MQCURL3FXsQWBryj1p X-Received: by 2002:a17:906:3004:: with SMTP id 4mr12188784ejz.381.1587827329083; Sat, 25 Apr 2020 08:08:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587827329; cv=none; d=google.com; s=arc-20160816; b=KlntQKuwgM6NSdts9RTxDqY/T/cPXivyBruWOZ7zF0PZ5FxnqbPtHSYHT32uWlnhB1 r5KJgCy6uvXP76BQ4s8ylmqw/kyrT0KcymqantC2PbrUpxQWGQBDh+fnFJy9aX355C1R i1T0o4dl4P+gWsLWNX7gbHE8+U+5fcEVSBwFAZbLA9eyLZ0kIFy3E1/taLWYNjDtSrp+ mjuTp7KnuMgS8w9bjo58MztIFD0dOxa9heb3ZuHGGdokR30f0/lB7sjUdBaJ7nq7IiNo k8LaZOZ3sxn37wVXpgVCf+GPeqQlMSP/dZqOazyiNI+Am+0eVMOBMaYcs9l1EvM21z0j 7Hyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :dkim-signature; bh=aFNkj/X0ARFk1lHudyAFFChBsuWKz++VCQGA+5bkEF4=; b=zxtTo4tRtIZBag/cOrdviqfgI/uRcQQ+zWmdHbrsTKFsEPj/deTnSDycQs61QiBpfP IUiopT9YeoSv277nODturpVWRhd9PfUa851YmIdbMsGOAFQeW2uJ4MKnw/OK9LrimzSC h5iQ+BfC/46So+a9YeMfd38Ue319zwzY2syQcaBKbhJBbrMfBC0ymaf/t88k6gI6poHc 4YFtKPApdGCCM5/8gfHTGR8s7e6a183jSoQ909rqfrEFpxrnu7xngPIWjTe1RGLbsa77 kV5WyEmB9y8G6P8ARwShk1pRBdFl6HICw4iDMWe0WrcxQ+OIhwvRE4s7K5iqQNKBQVkE nq8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Qsh9H7XU; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bz11si5297564ejc.50.2020.04.25.08.08.25; Sat, 25 Apr 2020 08:08:49 -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=fail header.i=@gmail.com header.s=20161025 header.b=Qsh9H7XU; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726124AbgDYPEr (ORCPT + 99 others); Sat, 25 Apr 2020 11:04:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726102AbgDYPEq (ORCPT ); Sat, 25 Apr 2020 11:04:46 -0400 Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67117C09B04B for ; Sat, 25 Apr 2020 08:04:46 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id o135so967062qke.6 for ; Sat, 25 Apr 2020 08:04:46 -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; bh=aFNkj/X0ARFk1lHudyAFFChBsuWKz++VCQGA+5bkEF4=; b=Qsh9H7XUkaGUDZISgiDxKbDqE0iw0p/pS6gA7oFdel3Wd2F3lv0ULO/fCkynQ67oCW DqWtaidJKbBNrWGqbCP7qSK+SvwCC4f+9bp25MtF/7pRsPwDG6NvOxgGo3PFdQyTbK9U HgmY8uxbNL+ONgb2jjOi9yfcQlHZ4sRWWDIWKmQ3rc7aa5T8kHU8NYYx0yOoV4TFOvBB zcRXfwiHCdP6/1zuEF9vdLa2ESgC7uFkZYUp8cJLLXcV95+IwNuEuNW7EPeE5REcVFKe FtkmVOk/yIUksd6uHUEdCrZ9voizXd/hkn4tOTB0RkHU/FlwCcm37vjPXni2YIZIKT0r x0Ow== 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; bh=aFNkj/X0ARFk1lHudyAFFChBsuWKz++VCQGA+5bkEF4=; b=Q167AaacFgzvMt25+XlPliEsUI3oNnTwgxQOUloO0xVbC6m3mubIapPP28bJ8nB5kV 29H05ThLro+mJ+GSEAyHEzmXMmLJegmUQbOmTct1xVoLh5SM8aT3QZrddjVpvJbrkGkC e//z9A/jFbyP7wLrSdoyRptys05e6IKGGTVniexeUllh+yHGWqxNsEzbpIfm+tO1Q4Be fh00SrI33UUmlG4ImJQZskEjmhWrh/tjavFxvhoKwf7tq5asDBSRK951dHndnzg+Es7O RPzFMunHuaXPFayIigGZMwtHZDC/Kp/TvPnT7YLvAGHPS4BOSIC5glTGMZqIulXAK99H JHPg== X-Gm-Message-State: AGi0PuaESOI9iP+zsJcKvxW1wo54x8RBfN56FgHPYP0yqcBxz++O51o3 Xf7Vl/rGDvlJF7zLH6lqVv0= X-Received: by 2002:a37:e30e:: with SMTP id y14mr13686328qki.61.1587827085314; Sat, 25 Apr 2020 08:04:45 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id p10sm5925035qtu.14.2020.04.25.08.04.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Apr 2020 08:04:43 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Sat, 25 Apr 2020 11:04:40 -0400 To: Borislav Petkov Cc: Arvind Sankar , Nick Desaulniers , Michael Matz , Jakub Jelinek , Sergei Trofimovich , LKML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, clang-built-linux , Kees Cook , Martin =?utf-8?B?TGnFoWth?= , =?utf-8?Q?Fr=C3=A9d=C3=A9ric_Pierret_=28fepitre=29?= , boris.ostrovsky@oracle.com, jgross@suse.com, linuxppc-dev@lists.ozlabs.org, Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras Subject: Re: [PATCH] x86: Fix early boot crash on gcc-10, next try Message-ID: <20200425150440.GA470719@rani.riverdale.lan> References: <20200422102309.GA26846@zn.tnic> <20200422192113.GG26846@zn.tnic> <20200422212605.GI26846@zn.tnic> <20200423125300.GC26021@zn.tnic> <20200423161126.GD26021@zn.tnic> <20200425014657.GA2191784@rani.riverdale.lan> <20200425085759.GA24294@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200425085759.GA24294@zn.tnic> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 25, 2020 at 10:57:59AM +0200, Borislav Petkov wrote: > On Fri, Apr 24, 2020 at 09:46:57PM -0400, Arvind Sankar wrote: > > The comment above boot_init_stack_canary's definition should be updated > > to note that it needs to be called from a function that, in addition to > > not returning, either has stackprotector disabled or avoids ending in a > > tail call. > > How's that? > > diff --git a/arch/x86/include/asm/stackprotector.h b/arch/x86/include/asm/stackprotector.h > index 91e29b6a86a5..237a54f60d6b 100644 > --- a/arch/x86/include/asm/stackprotector.h > +++ b/arch/x86/include/asm/stackprotector.h > @@ -55,8 +55,12 @@ > /* > * Initialize the stackprotector canary value. > * > - * NOTE: this must only be called from functions that never return, > - * and it must always be inlined. > + * NOTE: this must only be called from functions that never return, it must > + * always be inlined and it should be called from a compilation unit for > + * which stack protector is disabled. > + * > + * Alternatively, the caller should not end with a function call which gets > + * tail-call optimized as that would lead to checking a modified canary value. > */ > static __always_inline void boot_init_stack_canary(void) > { I'd put the clause about stack protector being disabled and the tail-call one together, to make clear that you still need the never return and always inline bits. Also, this function is implemented by multiple arch's and they all have similar comments -- might be better to consolidate the comment in the generic (dummy) one in include/linux/stackprotector.h laying out the restrictions that arch implementations should follow? > > > There are also other calls that likely need to be fixed as well -- in > > init/main.c, arch/x86/xen/smp_pv.c, and there is a powerpc version of > > start_secondary in arch/powerpc/kernel/smp.c which may also be affected. > > Yes, there was an attempt to fix former: > > https://lkml.kernel.org/r/20200413123535.10884-1-frederic.pierret@qubes-os.org There's also the one in init/main.c which is used by multiple architectures. On x86 at least, the call to arch_call_rest_init at the end of start_kernel does not get tail-call optimized by gcc-10, but I don't see anything that actually prevents that from happening. We should add the asm("") there as well I think, unless the compiler guys see something about this function that will always prevent the optimization? Cc'ing PPC list for powerpc start_secondary.