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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 9F978C38A2D for ; Tue, 25 Oct 2022 15:29:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Cc:To:Subject: From:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dwe5DqDi2JUvhoz4Cgh6/rL5EF72cS3ysJosqNeN668=; b=dPha2LbHAze59i /0isBEBQX8d1L360beAcEpQIBbhNFXMR+pMHrR2kSVKvM+JST5FyGf+FypbhceO8h7S5/rpwZBWk5 m3MNXbe+OTESsSvSDJvBpJtts4FcO9/NPciaqKt05kuUHktGVUK9tjshCmd77cKISGLRVWYfEt4yk heMhRX6ClCwHNeE5bI38cuO1GxRPYKCJST9D0RS12Z1+IBISYKumYs3zfWNhrgVGmZD6KIzAgH4t7 upo1OPYrxsIGrUA8xC7OUqqVo8/ltdeYo1J+BNpKp9S7ntwe6EyT7bx5JPG3i1ELfnGiPpbodz8J7 Dvv9h8YH1/XRlmr2w2ZQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1onLqu-0065cB-TR; Tue, 25 Oct 2022 15:28:29 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1onLqn-0065Xg-68 for linux-arm-kernel@lists.infradead.org; Tue, 25 Oct 2022 15:28:22 +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 307ADD6E; Tue, 25 Oct 2022 08:28:22 -0700 (PDT) Received: from [10.57.1.104] (unknown [10.57.1.104]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C27A83F71A; Tue, 25 Oct 2022 08:28:13 -0700 (PDT) Message-ID: <4e50b890-0588-1551-fb7c-6cd8191d1054@arm.com> Date: Tue, 25 Oct 2022 16:28:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 From: James Clark Subject: Re: [PATCH v2 1/1] perf arm64: Send pointer auth masks to ring buffer To: Peter Zijlstra Cc: linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, broonie@kernel.org, acme@kernel.org, Andrew Kilroy , Vince Weaver , Mark Rutland , Ingo Molnar , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Will Deacon , Catalin Marinas , kristina.martsenko@arm.com References: <20221020101921.1219533-1-james.clark@arm.com> <20221020101921.1219533-2-james.clark@arm.com> Content-Language: en-US In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221025_082821_377360_3EE618AE X-CRM114-Status: GOOD ( 27.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 20/10/2022 17:49, Peter Zijlstra wrote: > On Thu, Oct 20, 2022 at 11:19:20AM +0100, James Clark wrote: >> From: Andrew Kilroy >> >> Perf report cannot produce callgraphs using dwarf on arm64 where pointer >> authentication is enabled. This is because libunwind and libdw cannot >> unmangle instruction pointers that have a pointer authentication code >> (PAC) embedded in them. >> >> libunwind and libdw need to be given an instruction mask which they can >> use to arrive at the correct return address that does not contain the >> PAC. >> >> The bits in the return address that contain the PAC can differ by >> process, so this patch adds a new sample field PERF_SAMPLE_ARCH_1 >> to allow the kernel to send the masks up to userspace perf. >> >> This field can be used in a architecture specific fashion, but on >> arm64, it contains the ptrauth mask information. The event will >> currently fail to open on architectures other than arm64 if >> PERF_SAMPLE_ARCH_1 is set. It will also fail to open on arm64 if >> CONFIG_ARM64_PTR_AUTH isn't set, as the data would always be zeros. > > A little more information please; wth is pointer authentication? Are we Yes the commit message could do with some links and details. I will add more background about the feature if I resend it. > going to be having the same thing with x86 LAM where only a subset of > the available bits have meaning to the hardware? If LAM is used with things like return addresses on the stack then yes. For data addresses then it wouldn't cause this exact issue. The problem is that libunwind and perf do pointer arithmetic when unwinding with other values that don't have these bits set. For example computing offset in an mmap where the base address doesn't have an authentication code but a return value does results in an incorrect value. Like x-y=offset is only correct if the PAC bits are masked out first. > > Why do we want the same mask repeated over and over with each sample; > should this not be part of the address space (side-band) data? You are probably right that it could be done that way. The reason that we did it this way was to be consistent with ptrace feature [1] where it is delivered to userspace on a per-process basis. And there is also a prctl for the enabled key types [2] which can be changed dynamically. Particularly for the last reason is why it was done per sample. Having said that, the enabled keys field is not used by perf, only the mask is used, so I can drop the per sample data until enabled keys is needed, which may be never. I'm going to assume that perf shouldn't use ptrace because of permissions and conflicts with debuggers, so I could put the mask somewhere like PERF_RECORD_FORK instead of per sample. [1]: https://lore.kernel.org/all/20181207183931.4285-9-kristina.martsenko@arm.com/ [2]: https://lore.kernel.org/all/d6609065f8f40397a4124654eb68c9f490b4d477.1616123271.git.pcc@google.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel