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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 83E36C433E0 for ; Tue, 2 Feb 2021 10:07:36 +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 1D11164E4F for ; Tue, 2 Feb 2021 10:07:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D11164E4F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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-Transfer-Encoding: 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-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wa5trhZYN2OUVWmARF6B0kBduvhNVi3AQMEIWRgX+UQ=; b=QD27Phfp0vfyRVbyovZ/d6Nyk TFqVIMsZ8FAdCl/cHokisYXYBcRkJ1kupBpQ2eY6DADDWzCXPpxhUgrYuJh+hmlU+dsh+F3sKdt6f oD/HHylNcw3s9D3zlsn7TVvbJL6uCKn7Ae3oUuvf9ZkZugmQjnwI4BZPd+pt3ksN+0B0WK3zU4PIO 9BbJsk1XZIwn+HF1175MnbFgyN/Q5PjwQKf8Xgcf/L1TE+2dzDtnIYf19J+JFzxGnY7/X+0w6+5Zm pLAoRY1wML1Pd5U7SJXi21Pzeicub6Tjof1AEnWTlwjKH6ve8W6nW5W3Bg2c8kqALne3V1S+AQkuY KdA/WfaZA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6sZg-0005rk-J9; Tue, 02 Feb 2021 10:06:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6sZa-0005qj-EX for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 10:06:18 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A1891396; Tue, 2 Feb 2021 02:06:07 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.49.77]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2C7183F7D7; Tue, 2 Feb 2021 02:06:04 -0800 (PST) Date: Tue, 2 Feb 2021 10:05:55 +0000 From: Mark Rutland To: "Madhavan T. Venkataraman" Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace Message-ID: <20210202100547.GA59049@C02TD0UTHF1T.local> References: <20201012172605.10715-1-broonie@kernel.org> <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> <20210128142250.GC4537@sirena.org.uk> <20210128152649.6zin3hzim3etbv2p@treble> <20210201160225.GD66060@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_050614_648161_5102DA92 X-CRM114-Status: GOOD ( 24.03 ) 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: Julien Thierry , Catalin Marinas , Mark Brown , Josh Poimboeuf , Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 01, 2021 at 03:38:53PM -0600, Madhavan T. Venkataraman wrote: > On 2/1/21 10:02 AM, Mark Rutland wrote: > > On Mon, Feb 01, 2021 at 09:21:43AM -0600, Madhavan T. Venkataraman wrote: > >> On 1/28/21 9:26 AM, Josh Poimboeuf wrote: > >> Decoding > >> ======== > >> > >> To do all this, objtool has to decode only the following instructions. > >> > >> - no-op > >> - return instruction > >> - store register pair in frame pointer prolog > >> - load register pair in frame pointer epilog > >> > >> This simplifies the objtool part a lot. AFAIK, all instructions in ARM64 are > >> 32 bits wide. So, objtool does not have to decode an instruction to know its > >> length. > >> > >> Objtool has to scan a function for the return instruction to know the location(s) > >> of the epilog. > > > > That wouldn't be robust if you consider things like: > > > > | func: > > | STP x29, x30, [SP, #-FRAME_SIZE]! > > | MOV X29, SP > > | B __fake_ret > > | LDP X29, X30, [SP], #FRAME_SIZE > > | RET > > | __fake_ret: > > | BL x30 > > > > ... which is the sort of thing we want objtool to catch. > > Objtool has to follow all the code paths to check every single possible return > as I mentioned above. Here I was pointing out that in order to do so you need to decode and reason about more than NOP, RET, STP, and LDP, and you need to reason about the logical function of an instruction (e.g. here the last LDP is emulating a RET). > > > [...] > > > >> Unwinder logic > >> ============== > >> > >> The unwinder will walk the stack using frame pointers like it does > >> currently. As it unwinds the regular stack, it will also unwind the > >> shadow stack: > >> > >> However, at each step, it needs to perform some additional checks: > >> > >> symbol = lookup symbol table entry for pc > >> if (!symbol) > >> return -EINVAL; > >> > >> if (symbol does not have proper prolog and epilog) > >> return -EINVAL; > > > > I think at this point, we haven't gained anything from using a shadow > > stack, and I'd much rather we used objtool to gather any metadata needed > > to make unwinding reliable without mandating a shadow stack. > > > > I think we have gained something. Pushing the return addresses on the shadow stack > and using them to unwind means that objtool does not have to decode every single > instruction and track the changes to the stack and frame state. I think that practically speaking it's necessary to track all potential paths through functions that may alter the shadow stack or the shadow stack pointer to ensure that the manipulation is well-balanced and that the shadow stack pointer isn't corrupted. Practically speaking, this requires decoding a significant number of instructions, and tracing through all potential paths a function may take. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel