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=-2.5 required=3.0 tests=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 ABE92C2BA19 for ; Tue, 14 Apr 2020 11:01:06 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 7150F2072D for ; Tue, 14 Apr 2020 11:01:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="L/Nd6BKx"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="HjUjbR/e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7150F2072D 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+infradead-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=bombadil.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=ZbgN95KHJxe8sgM8x/mUoBLqTk3mhfDF8sM2D8sxm6Y=; b=L/Nd6BKxyiyE15 DSo+cVsVuZQm8NGGQgTIbTRkda0UX6a7SXtPmpMJ/h6hA1RoOyXzzYNQYpjlc0ijC3nAhHaSDSH07 aKernMug889aFwIPsv9eW+HIZGovEBSWYwYitZlda3gdM/y5XdyAL1eEiVz9Fjbs+xk+K0grzISCD M742dMaCPCaMOEqSmusLinsYcu2uRkMoWxr8rlXKQwDM12Kz9SUjI1iqzadOZzzT1R1+OokZcxQnJ T0r0n9zE/tL62iRzSrFSmrekgL2vLDoQZVmzb2yZxN9Bb5yJfu12x11y+RVMOCBsxJCXFNc4VVKUn 5vxs8n5nUQBydZgbWJ9A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jOJJR-0007D0-50; Tue, 14 Apr 2020 11:01:05 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jOJJO-0007CU-HE for linux-arm-kernel@lists.infradead.org; Tue, 14 Apr 2020 11:01:03 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 83C902072D; Tue, 14 Apr 2020 11:01:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586862061; bh=4KfkzKJjz5RIUKdgy04cqT3v8IcNTwfDjxLuBg15CKU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HjUjbR/eiLWaR/rDWLBvSriLUazACWu9IaPJimMjkgUuwRFzpxmQEWuctrVnt0O40 kO/dk94ki+h5trKnGOadhSJHifqvgY+Y/DpZJDv++GbgAPrRgQvpgD3nt8QfrW0kKG 57kDP7JH40nT7fI2TvXBM/ERgQ8qjIEqvrTldtA0= Date: Tue, 14 Apr 2020 12:00:56 +0100 From: Will Deacon To: Mark Rutland Subject: Re: [PATCH] arm64: Optimize ptrauth by enabling it for non-leaf functions Message-ID: <20200414110056.GB26395@willie-the-truck> References: <1586856741-26839-1-git-send-email-amit.kachhap@arm.com> <20200414100033.GA26395@willie-the-truck> <20200414101649.GC1278@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200414101649.GC1278@C02TD0UTHF1T.local> 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-20200414_040102_591454_9786B93B X-CRM114-Status: GOOD ( 14.61 ) 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: Catalin Marinas , Mark Brown , James Morse , Amit Daniel Kachhap , Vincenzo Frascino , linux-arm-kernel@lists.infradead.org, Daniel Kiss Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 14, 2020 at 11:16:49AM +0100, Mark Rutland wrote: > On Tue, Apr 14, 2020 at 11:00:33AM +0100, Will Deacon wrote: > > On Tue, Apr 14, 2020 at 03:02:21PM +0530, Amit Daniel Kachhap wrote: > > > Compilers are optimized to not store the stack frame record for the leaf > > > function in the stack so applying pointer authentication in the leaf > > > function is not useful from security point of view. > > > > I'm missing the reasoning here -- why don't we care about leaf functions? > > > > Sounds like there's a performance/security trade-off that needs spelling > > out and justifying with some numbers, or is it clear-cut and I'm missing > > something? > > I believe this is because leaf functions don't store the LR to the stack > (as they don't create a frame record), so it cannot be modified by a > stray memory write. That makes some sense, but doesn't it also mean you can jump into the middle of a leaf function and it will happily return to whatever sits in LR? Perhaps it would make sense to relax to the 'non-leaf' version only if stack protector is enabled? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel