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 698A5C433F5 for ; Mon, 18 Apr 2022 18:39:58 +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:From:References:Cc:To: Subject: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=DF1VnIbf5f2twlODj1j2gzP8IygUN8nLXrMbn7yx4D0=; b=wkpKmZYfyzR/dJ dZTEPZivlHVGaOW1dqR1QQ02Q8WhZKNQerm2wplQJQCdMlB2a0HoDY2Gk4uDzJzgfAVoIiz+F0R1v ryNKR1ezYjOn9D2Z1ocCiVLO6wOByU2ptSrZxdJhv7SnHn9lAWudu2xT/gy3D6nUnSrBkBJ1WzOpJ 7L60+qEuf0TNlqmfxg3DybbfhVERbM5W/WLexNIht1q1AU8z02SomvCzHltpNc3UP5cwGOSchrKOB fodAliO12fuEkpuJ4RAF/4EW+CXkLmhnSUSzfq4+jmce3FY4K+FK6T8Hh/ErUkVuJtLQurgfvZU+N ylhUOSV9MiX9m6tjUquA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngWH4-000LkI-Ab; Mon, 18 Apr 2022 18:38:58 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngWH1-000Lil-KV for linux-arm-kernel@lists.infradead.org; Mon, 18 Apr 2022 18:38:56 +0000 Received: from [192.168.254.32] (unknown [47.189.24.195]) by linux.microsoft.com (Postfix) with ESMTPSA id D817320C3609; Mon, 18 Apr 2022 11:38:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D817320C3609 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1650307132; bh=H8MyfPervZyuNt3r3vstdEuHzcoj4KqWTgx18POqIdA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VCRFtQ/Oere8emSN1kRUq5qJ/USQF9Y3CrlpBuBMAXTs9hWhhhcL4s2wFZtCIi4Cu 1KssUGysj8cYkXnJARC05+b8ief9dY6f3mCjxYs+8AAG1baC+E0OaTrdtzlehbCxfZ VA3jd3RotO1haVys02m+8VSWn33q4rM+ThZc1y24= Message-ID: Date: Mon, 18 Apr 2022 13:38:51 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH v1 0/9] arm64: livepatch: Use DWARF Call Frame Information for frame pointer validation Content-Language: en-US To: Josh Poimboeuf , Chen Zhongjin Cc: mark.rutland@arm.com, broonie@kernel.org, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <95691cae4f4504f33d0fc9075541b1e7deefe96f> <20220407202518.19780-1-madvenka@linux.microsoft.com> <20220408002147.pk7clzruj6sawj7z@treble> <15a22f4b-f04a-15e1-8f54-5b3147d8df7d@linux.microsoft.com> <35c99466-9024-a7fd-9632-5d21b3e558f7@huawei.com> <20220416005609.3znhltjlhpg475ff@treble> <0abfa1af-81ec-9048-6f95-cf5dda295139@huawei.com> <20220418161145.hj3ahxqjdgqd3qn2@treble> From: "Madhavan T. Venkataraman" In-Reply-To: <20220418161145.hj3ahxqjdgqd3qn2@treble> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220418_113855_741287_9A8DF6EF X-CRM114-Status: GOOD ( 13.90 ) 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 4/18/22 11:11, Josh Poimboeuf wrote: > On Mon, Apr 18, 2022 at 08:28:33PM +0800, Chen Zhongjin wrote: >> Hi Josh, >> >> IIUC, ORC on x86 can make reliable stack unwind for this scenario >> because objtool validates BP state. >> >> I'm thinking that on arm64 there's no guarantee that LR will be pushed >> onto stack. When we meet similar scenario on arm64, we should recover >> (LR, FP) on pt_regs and continue to unwind the stack. And this is >> reliable only after we validate (LR, FP). >> >> So should we track LR on arm64 additionally as track BP on x86? Or can >> we just treat (LR, FP) as a pair? because as I know they are always set >> up together. > > Does the arm64 unwinder have a way to detect kernel pt_regs on the > stack? If so, the simplest solution is to mark all stacks with kernel > regs as unreliable. That's what the x86 FP unwinder does. > AFAICT, only the task pt_regs can be detected. For detecting the other pt_regs, we would have to set a bit in the FP. IIRC, I had a proposal where I set the LSB in the FP stored on the stack. The arm64 folks did not like that approach as it would be indistinguishable from a corrupted FP, however unlikely the corruption may be. Unwind hints can be used for these cases to unwind reliably through them. That is probably the current thinking. Mark Rutland can confirm. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel