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,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 2D1ACC433E0 for ; Tue, 2 Feb 2021 13:34:39 +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 DBCE464F5D for ; Tue, 2 Feb 2021 13:34:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBCE464F5D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.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:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Qxy0o4ooldRIhja4DxHcPIbGW5YBzyKjXos9ND0MrrI=; b=cr/EaoK2xFnTfeSpTeHYgoAme WbW3PX4o5l/9AgrE7wc1lYRIutlrUyw9vI0aAEfeGIXVkJyIsHg8gOlydY2qxwGwveYVJm4iRDiLl Fci7nQhzD416DTaEL8a8uuZ9vTnToM4vuj9gUdyflKN2dX2tLHton2ziRUgHtUrRoKGUtkhSzT35t JRIJhT77MZxlnwWexA/TVu9OOXLTsNEEFJXKRwxBb6KHGc8TVDcc7ZF4AbT9RFKq26K1QrM2da1DI hXlsw+p4MaEXEMmaA7n75e+lzOuiEZyCWDWjBi8t8tJ2wGQg90LaNEwBBCz80NfOO3239mIN6CHfi 2ybz305gw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6voE-0001gE-6a; Tue, 02 Feb 2021 13:33:34 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6voC-0001f8-9M for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 13:33:33 +0000 Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id 1748820B7192; Tue, 2 Feb 2021 05:33:30 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1748820B7192 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1612272810; bh=7kz9rcY9gKPvU11JwcqSfBgBGx2XMvl4HCNgwANrQDI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CNh00tSqH1Ay3sVLT9JhiprSElhKHoEroNc49PADdzTNJK/RA422IOQgAGFmM22SF +3EQeoqqjyWyzG/6C6vbreDZG/KLJZoQTuSDA73uFBqjubOJHbDOl+NteyI+iu6KI5 df+6Kl9MHsr1Ig8MNhggZGGxyWttF7M8/+r6GayA= Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace To: Mark Rutland 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> <20210202100547.GA59049@C02TD0UTHF1T.local> From: "Madhavan T. Venkataraman" Message-ID: <0a338e27-40fb-51c3-bff9-1b379339daec@linux.microsoft.com> Date: Tue, 2 Feb 2021 07:33:29 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210202100547.GA59049@C02TD0UTHF1T.local> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_083332_533520_89B4E6AE X-CRM114-Status: GOOD ( 17.15 ) 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 2/2/21 4:05 AM, Mark Rutland wrote: >>> 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. I am not sure why the shadow stack should be modified by any function. It is a shadow stack. Functions are not supposed to be aware of it (except for the prolog and epilog). For C functions, the compiler would reserve the shadow stack pointer register and not use it for anything other than prolog and epilog. If the worry is that some kernel developer may unknowingly use the register in assembly code and we need to catch this during kernel build, we can do it using grep. The only code that is allowed to modify it is the macros that we define for prolog and epilog. This can be done using a simple script. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel