From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AD88C433DB for ; Thu, 28 Jan 2021 14:24:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 06E8B64D9F for ; Thu, 28 Jan 2021 14:24:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06E8B64D9F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qxQcRoN9qSesLEct18H5WT0EjhN2/IBMIkB5sEWlBjQ=; b=JKbwrD3QyRqGlCbsnPMNoKd1b 9Jcd9g/XcvpGEHwOqjwt3dO5gw43HezxhnFo0AtCGml7Ib/KKMYfWvbleF8PHxOaiYvLZch9wOVIY QpA9S+qmPSjTiez179UT47AIn4HqZK8fwLurhAK/vX/OitPTYpYEg0Pwbw1tfm6KIyXCOMJyfBuQA fTbkBIEBe4N/Y2/SA2oCkHANVxUt9i0a2xP9IETDrFWS7qvrV8DtA/cUfGbVhQUsaVfFDI6W7iHJ+ x56kKcA3UrBhseGRoljmtRIHfQwO0ZFI+QKQcic9hYrb67RJqEAIaajApShVsIBOAa6pEhPT+FXC8 QxbLbBReA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l58Cy-0005UP-3U; Thu, 28 Jan 2021 14:23:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l58Cu-0005Sh-VG for linux-arm-kernel@lists.infradead.org; Thu, 28 Jan 2021 14:23:37 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B70BB64DDE; Thu, 28 Jan 2021 14:23:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611843815; bh=KYt4dMJIyPAyrE5q5k9CKbpxYYa9H84Fbceozn9D+/g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TIVqqQVjE27vIJrIQml8S/U6k9mDPLmoUc8oXQ59rhV3n+Pbt2tw0CUmSDyTW0MtY 9hONKi//TPP8R03+/69sgXh29lS6gSecCRpZV79nOZbalgvPaIkXNoq5hDCzNXsfau wuQHdwLYyuskaYSHKI+OQtXvPbLNsKBC03QiPIyNtRGf0e2JoPTdMyq4utvfaDZjMH xzQtt+3iP0IGkCmC/4EWnsYnkUDNOmd2n1b4XMT3b5/BlbBi/YSrmE5QkJYlDemIfA 4+KK7uLSVI1WV/3VTkPFkxpYyfNmYmbFNYpPB39incTxytGCP20rvLKk2dscPQ2Yym jv+yupn9+Vtcw== Date: Thu, 28 Jan 2021 14:22:50 +0000 From: Mark Brown To: "Madhavan T. Venkataraman" Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace Message-ID: <20210128142250.GC4537@sirena.org.uk> References: <20201012172605.10715-1-broonie@kernel.org> <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> MIME-Version: 1.0 In-Reply-To: <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> X-Cookie: Do not pick the flowers. User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210128_092337_182055_D376D38F X-CRM114-Status: GOOD ( 34.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Julien Thierry , Catalin Marinas , jpoimboe@redhat.com, Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============0235967336620925783==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============0235967336620925783== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 27, 2021 at 01:54:21PM -0600, Madhavan T. Venkataraman wrote: Copying in Julien and Josh for the objtool stuff. I'm replying here but I'm not 100% up to speed yet so take what I say with a grain of salt. > FP and no-FP functions > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This terminology is a bit confusing to me, I keep expanding FP to floating point here. Perhaps stack maintanance? > I have a suggestion for objtool and the unwinder for ARM64. >=20 > IIUC, objtool is responsible for walking all the code paths (except unrea= chable > and ignored ones) and making sure that every function has proper frame po= inter > code (prolog, epilog, etc). If a function is found to not have it, the ke= rnel > build is failed. Is this understanding correct? Roughly, AIUI. > If so, can we take a different approach for ARM64? This feels like something that should just be a stack protector feature rather than something that an individual architecture should be striking out on its own with. > Instead of failing the kernel build, can we just mark the functions as: > FP Functions that have proper FP code > no-FP Functions that don't > May be, we can add an "FP" flag in the symbol table entry for this. > Then, the unwinder can check the functions it encounters in the stack tra= ce and > inform the caller if it found any no-FP functions. The caller of the unwi= nder can > decide what he wants to do with that information. >=20 > - the caller can ignore it >=20 > - the caller can print the stack trace with a warning that no-FP functio= ns > were found >=20 > - if the caller is livepatch, the caller can retry until the no-FP funct= ions > disappear from the stack trace. This way, we can have live patching ev= en > when some of the functions in the kernel are no-FP. >=20 > Does this make any sense? Is this acceptable? What are the pitfalls? One downside of this would be that we'd need some way of figuring out if we've got enough of the kernel covered to be actually useful for livepatch, and it does mean that we'll have some percentage of code where the debugging uses for unwinding will be impacted. It does seem like it's broadly the distinction between the existing standard and reliable stacktrace interfaces but pushed into the callback, however reliable stacktrace is going to also perform additional checks like looking for conditions that might leave things in an inconsistent state (eg, finding probes or interrupts being taken) so the distinction isn't just in the binary but also other runtime conditions. Reliable stacktrace can also make assumptions that the task is not currently running unless it is the task doing the trace. =20 There was actually until very recently a flag on the callback that is provided to arch_stack_walk() which indicated if things were supposed to be reliable but there were no users and nothing ever changed the value, there was something in a comment or changelog somewhere which said that this had been for the benefit of printk() but the user had never been merged. That sounds a lot like what you're suggesting. > If we can do this, the unwinder could detect cases such as: > - If gcc thinks that a function is a leaf function but the function conta= ins > inline assembly code that calls another function. > - If a call to a function bounces through some intermediate code such as a > trampoline. > - etc. > For specific no-FP functions, the unwinder might be able to deduce the or= iginal > caller. In these cases, the stack trace would still be reliable. For all = the others, > the stack trace would be considered unreliable. I'm not entirely sure I see the distinction from the current situation here? > Compiler instead of objtool > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > If the above suggestion is acceptable, I have another suggestion. >=20 > It is a lot of work for every new architecture to add frame pointer verif= ication > support in objtool. Can we get some help from the compiler? >=20 > The compiler knows which C functions it generates the FP prolog and epilo= g for. It can > mark those functions as FP. As for assembly functions, kernel developers = could manually > annotate functions that have proper FP code. The compiler/assembler would= mark them > as FP. Only a small subset of assembly functions would even have FP prolo= g and epilog. > Is this acceptable? What are the pitfalls? If we're trusting the compiler we can probably just do that without any explicit support from the compiler - it should be doing the standard stuff unless we explicitly ask it to and if it isn't then it might be a result of a mismatch in assumptions rather than a deliberate decision to do something non-standard. My understanding with objtool is that a big part of the idea is to provide a static check that the binary we end up with matches the assumptions that we are making so the fact that it's a separate implementation is important. > This can be implemented easily for all architectures for which the compil= er generates > FP code. >=20 > Can this be implemented using a GCC plugin? I know squat about GCC plugin= s. >=20 > Thanks! >=20 > Madhavan >=20 >=20 >=20 >=20 --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmASyLoACgkQJNaLcl1U h9DUJQf/eK5epmzaghrRdFrapk2pHw6Kq8EzIIUbxaqq0/2IChbQazh+IBHjWNtz ZDy0/YDYgzBcXEgH3fJFWnXahrvDtqOVwzx/YUkwCEPqzvw30MYtiFRL3gC/hau0 QzkmrBP4R91whtBTSSfTrFRbRX56Gg+/iv85zX5Gp0qvxNIvNI6YQ1SIzfx9uXln IwGP2RK4tS67TtpWBQGg8XBxW79l25oJTYPj1v0lkhx0Ub3TqxISaLzvTd5ZhQn1 1S7zXoYbiMc1rw7VjYnDfPE4Wy2d5MEcwk/CcfGMxdSS+UXj6CRDzY1sfEfrU1sT wG6EDYdkAlTqY7fyxwo4e0MLVfe9Sw== =OEFs -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- --===============0235967336620925783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============0235967336620925783==--