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 B9E32C433E0 for ; Tue, 2 Feb 2021 23:33:53 +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 606A464E4D for ; Tue, 2 Feb 2021 23:33:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 606A464E4D 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:References: To:Subject:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ysili6IrsYCZOJjZ+XG8o7nFo53I9z+poezNk7A5by4=; b=sFkSR59H/el64tdPpJTClcNko nEX7w1XtU1FZo1AIL090kgBVyNgi9aRWS1IENx4QwGwJmLG14+maGDaIbGkSZEJ69EqL3GXkk4Kw9 Ts92IpzRAeB32BV6JxU3cvu2m42bV8ftQWggHdIkOsberCs56Q+w1EvR89YGgy4bfs8wKC/rGmLZ5 iWOUB/fmvsXygMYSQXWc9IP2A52WH/MJetu5UHpRDRXh44q3tIdJ+0oyzDaV8jokb5rHR+Hb6j78q sABBji5Y4imzIWZrlFxTtbY3awAdhppzmuRVFTtM1wg8tnh8MXyP8rCttp9sqyBQV2yNS1xuluOsF xqCFCGFUQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l759z-0004Rs-OL; Tue, 02 Feb 2021 23:32:39 +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 1l759v-0004Qk-Uq for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 23:32:37 +0000 Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id C2F3E20B7192; Tue, 2 Feb 2021 15:32:33 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C2F3E20B7192 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1612308754; bh=bnfGbgdDgzGxG8EPJ+uNpXDZ8U/j2VXL2hMk4hBjr9E=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=eWMQWfh6PHKK6JPtIsOAeoJb4Xp6hVQ5A2hyMv4b69hIJk7S4dbnc0vCyg33Xq1jO wqXHks3nmn00Vr6E0nJ9ZqPqQUA8GQW6wNZoRZLhMCdmmyLIUUNj9lzCiS55V3lnVb Q8wfj3dNScUiTwJHRaMr7Kt6ZnW3z5ps5CUCVbEQ= From: "Madhavan T. Venkataraman" 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> Message-ID: Date: Tue, 2 Feb 2021 17:32:32 -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_183236_302509_53E9633F X-CRM114-Status: GOOD ( 19.38 ) 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 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 thought about it some more since you don't like the shadow stack that much. I think I can achieve what I want with a simpler design without any shadow stack and with better performance than a shadow stack. It needs a slightly changed prolog and epilog. Please review this and comment. In this design, I need 8 bytes of storage for recording the current frame pointer address. Space at the bottom of the stack can be reserved for this easily. I will use cur_fp to refer to the value at that memory location. For this discussion, fp refers to the frame pointer register and sp refers to the stack pointer register. The goal is - even if a function modifies fp and/or does not restore sp to its correct value at the end, the prolog and epilog should manage it so that everything works. To do this, the current frame pointer address is stored in fp as well as cur_fp. Even if fp is modified, cur_fp will still point to the correct frame address. Prolog ======= The original prolog is: - Push fp and return address on the stack - fp = sp The new prolog is: - Save cur_fp on the stack - Push fp, return address on the stack - fp = sp - cur_fp = fp Epilog ====== The original epilog is: - Pop fp and return address The new epilog is: - sp = cur_fp - Pop fp and return address - Restore cur_fp from the stack I think this is pretty simple. Unwinder ======== The unwinder will start the stack walk from cur_fp instead of fp. At each frame, it will use the saved cur_fp instead of the saved fp. Also, at each step, it can know if fp was actually changed by the function in the frame. The unwinder can optionally issue warnings. Compiler issue =============== This solution is geared towards the kernel only. It assumes that the stack has a fixed size and alignment so the bottom of the stack can be reached from the current sp. So, the compiler has to support two prologs and epilogs, one pair for apps and one pair for the kernel. Since this is just a tiny bit of code, I don't think this is a problem. Finally, objtool can verify the prolog and epilog. Is this general solution acceptable? We can always work out details. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel