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.3 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 5E153C433DB for ; Wed, 3 Feb 2021 16:55:18 +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 004EC64F7C for ; Wed, 3 Feb 2021 16:55:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 004EC64F7C 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=Vdr8RA6MLASt4Lii0zE50yJWqXFpBouNfU2dtS71knQ=; b=BfxdIsNMCds3asS6Vzn8V2zDA CgNd0PaXw1foqdhhYOeHv6EfVYKhw38dClnKZsHF33URWzTOS2nW0cL/Ujx1PcCWZHfybVPmU8pk7 43kZZA8aY1lKw2Syuju48F30vJ8zNoacq35pAccBu//8Q7bARwYWPqR0ta8Io2uyYO8ILNsuJeb3T Z6mB5WpJlhl39a15jhlR4Hpr9GQiibmasPIFaHL24/LfLHPZPOpYRXFoP+RQZnol+amfELgyN8GB3 i+42vRR+ASfQ+bE1ays+NDwHmTTuSG55W+ZEpDf1fZbi/ysLiK22cN+s9HShnwUKkBf5owZ7toI+E KTKxGSM9Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7LPt-0004Y1-KY; Wed, 03 Feb 2021 16:54:09 +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 1l7LOw-00045A-Mf for linux-arm-kernel@lists.infradead.org; Wed, 03 Feb 2021 16:53:14 +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 C753FD6E; Wed, 3 Feb 2021 08:53:06 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.11.206]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5AC0A3F719; Wed, 3 Feb 2021 08:53:05 -0800 (PST) Date: Wed, 3 Feb 2021 16:53:02 +0000 From: Mark Rutland To: "Madhavan T. Venkataraman" Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace Message-ID: <20210203165302.GO55896@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> <20210202100547.GA59049@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-20210203_115311_261048_5AB11C86 X-CRM114-Status: GOOD ( 32.25 ) 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 Tue, Feb 02, 2021 at 05:32:32PM -0600, Madhavan T. Venkataraman wrote: > 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. Just to be clear, what I was trying to get across was: * Whatever we do, we want to verify at compile time that the kernel binary matches our expecations, and practically speaking this almost certainly means using objtool. * The analysis that objtool will have to do is not made significantly simpler through the use of a shadow stack, as it still needs to track all paths though a function, etc. I'm not averse to using a shadow stack (and clang's SCS is a useful security feature), I just don't think that it helps much with compile-time verification, and I don't see a strong reason to mandate it for livepatching. [...] > 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. I'm afraid I don't understand the problem you're trying to solve here. The epilog you propose is also unsound in the face of asynchronous exceptions, so I suspect you haven't thought as hard about this as you need to. Even if the compiler uses a different prologue/epilogue sequence, we still need to verify that the rest of the function does nothing to undermine that. I think this is merely different rather than simpler, and regardless this would be an invasive change to compilers. > 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. So this is just about aditional robustness? I'm happy to use a shadow stack for /additional/ robustness, I just don't think a shadow stack alone solves all the other issues that we need compile time verification for, nor does it solve cases where we might want metadata generated at compile time. > 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. I suspect it's more compilated than that. Configuration differences like this can easily double the necessary testing, and are liable to becomer a maintenance burden, so I don't expect compiler folk are likely to want to support this unless necessary. At the moment, I don't think that this solves a real problem, and I don't think that we need to change this. In future, we might want to agree some constraints with toolchain folk if we have specific concerns or pain points, but I don't think we've actually enumerated those and why we can't solve them through over means. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel