From: Chen Zhongjin <chenzhongjin@huawei.com>
To: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
<jpoimboe@redhat.com>, <peterz@infradead.org>,
<mark.rutland@arm.com>, <broonie@kernel.org>,
<nobuta.keiya@fujitsu.com>, <sjitindarsingh@gmail.com>,
<catalin.marinas@arm.com>, <will@kernel.org>,
<jamorris@linux.microsoft.com>,
<linux-arm-kernel@lists.infradead.org>,
<live-patching@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 11/20] objtool: arm64: Walk instructions and compute CFI for each instruction
Date: Mon, 30 May 2022 09:44:37 +0800 [thread overview]
Message-ID: <28642a99-0b59-a5dd-aea4-6c1db65c0934@huawei.com> (raw)
In-Reply-To: <ad2368a3-17fd-ad7e-95e8-0b7fa9b59fec@linux.microsoft.com>
Hi,
On 2022/5/29 23:18, Madhavan T. Venkataraman wrote:
>
>
> On 5/24/22 08:45, Chen Zhongjin wrote:
>> Hi,
>>
>> On 2022/5/24 8:16, madvenka@linux.microsoft.com wrote:
>>> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>>>
>>> Implement arch_initial_func_cfi_state() to initialize the CFI for a
>>> function.
>>>
>>> Add code to fpv_decode() to walk the instructions in every function and
>>> compute the CFI information for each instruction.
>>>
>>> Implement special handling for cases like jump tables.
>>>
>>> Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
>>> ---
>>> tools/objtool/arch/arm64/decode.c | 15 +++
>>> tools/objtool/fpv.c | 204 ++++++++++++++++++++++++++++++
>>> 2 files changed, 219 insertions(+)
>> ...
>>> +static void update_cfi_state(struct cfi_state *cfi, struct stack_op *op)
>>> +{
>>> + struct cfi_reg *cfa = &cfi->cfa;
>>> + struct cfi_reg *regs = cfi->regs;
>>> +
>>> + if (op->src.reg == CFI_SP) {
>>> + if (op->dest.reg == CFI_SP)
>>> + cfa->offset -= op->src.offset;
>>> + else
>>> + regs[CFI_FP].offset = -cfa->offset + op->src.offset;
>> Seems wrong here, we don't have any op->src.offset for [mov x29, sp] so here we
>> get: fp->offset = -cfa->offset. The dumped info also proves this.
>
>
> See the example below.
>
>>
>>> + case UNWIND_HINT_TYPE_CALL:
>>> + /* Normal call */
>>> + frame->cfa += orc->sp_offset;
>>> + fp = frame->cfa + orc->fp_offset;
>>> + break;
>> Obviously this is not conform to the reliability check because we get
>> frame->cfa == fp here.
>>
>
> See the example below:
>
>> IIUC your sp_offset equals to stack length, and fp_offset is offset from next
>> x29 to next CFA. So maybe here we should have
>> regs[CFI_FP].offset = regs[CFI_SP].offset for [mov x29, sp].
>>
>> Anyway, in original objtool sp_offset and fp_offset both represents the offset
>> from CFA to REGs. I think it's better not spoiling their original meaning and
>> just extending.
>>
>>
>
> I am not spoiling anything.
>
>
> Let us take an example:
>
> ffff800008010000 <bcm2835_handle_irq>:
> ffff800008010000: d503201f nop
> ffff800008010004: d503201f nop
> ffff800008010008: d503233f paciasp
> ffff80000801000c: a9be7bfd stp x29, x30, [sp, #-32]!
> ffff800008010010: 910003fd mov x29, sp
> ffff800008010014: f9000bf3 str x19, [sp, #16]
>
>
> The stack pointer is first moved by -32 and the FP and LR are stored there.
> At this point, SP is pointing to the frame. The CFA is:
>
> CFA = SP + 32
>
> The frame pointer has been stored at the location pointed to by the SP.
> So, FP should be:
>
> FP = CFA - 32
>
> Therefore, at instruction address ffff800008010014:
>
> frame->cfa = SP + 32;
> frame->fp = frame->cfa - 32 = SP;
>
> So, if a call/interrupt happens after this instruction, the frame pointer computed
> from the above data will match with the actual frame pointer.
>
> I have verified this using the DWARF data generated by the compiler. It is correct.
> I have also verified that the stack trace through such code passes the reliability
> check. That is, it computes the frame pointer correctly which matches with the
> actual frame pointer
You are right, I think I mixed up frame of x86 and arm64.
Apologize for that and thanks for explaining!
Best,
Chen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-30 1:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <e81e773678f88f7c2ff7480e2eb096973ec198db>
2022-05-24 0:16 ` [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation madvenka
2022-05-24 0:16 ` [RFC PATCH v2 01/20] objtool: Reorganize CFI code madvenka
2022-05-24 0:16 ` [RFC PATCH v2 02/20] objtool: Reorganize instruction-related code madvenka
2022-05-24 0:16 ` [RFC PATCH v2 03/20] objtool: Move decode_instructions() to a separate file madvenka
2022-05-24 0:16 ` [RFC PATCH v2 04/20] objtool: Reorganize Unwind hint code madvenka
2022-05-24 0:16 ` [RFC PATCH v2 05/20] objtool: Reorganize ORC types madvenka
2022-05-24 14:27 ` Chen Zhongjin
2022-05-29 15:36 ` Madhavan T. Venkataraman
2022-05-24 0:16 ` [RFC PATCH v2 06/20] objtool: Reorganize ORC code madvenka
2022-05-24 0:16 ` [RFC PATCH v2 07/20] objtool: Reorganize ORC kernel code madvenka
2022-05-24 0:16 ` [RFC PATCH v2 08/20] objtool: arm64: Implement decoder for FP validation madvenka
2022-05-24 0:16 ` [RFC PATCH v2 09/20] objtool: arm64: Implement command to invoke the decoder madvenka
2022-05-24 14:09 ` Mark Brown
2022-05-29 14:49 ` Madhavan T. Venkataraman
2022-05-30 7:51 ` Peter Zijlstra
2022-06-01 22:45 ` Madhavan T. Venkataraman
2022-06-07 18:13 ` Madhavan T. Venkataraman
2022-05-24 0:16 ` [RFC PATCH v2 10/20] objtool: arm64: Compute destinations for call and jump instructions madvenka
2022-05-24 0:16 ` [RFC PATCH v2 11/20] objtool: arm64: Walk instructions and compute CFI for each instruction madvenka
2022-05-24 13:45 ` Chen Zhongjin
2022-05-29 15:18 ` Madhavan T. Venkataraman
2022-05-30 1:44 ` Chen Zhongjin [this message]
2022-05-24 0:16 ` [RFC PATCH v2 12/20] objtool: arm64: Generate ORC data from CFI for object files madvenka
2022-05-24 0:16 ` [RFC PATCH v2 13/20] objtool: arm64: Dump ORC data present in " madvenka
2022-05-24 0:16 ` [RFC PATCH v2 14/20] objtool: arm64: Add unwind hint support madvenka
2022-05-24 0:16 ` [RFC PATCH v2 15/20] arm64: Add unwind hints to specific points in code madvenka
2022-05-24 0:16 ` [RFC PATCH v2 16/20] arm64: Add kernel and module support for ORC madvenka
2022-05-24 0:16 ` [RFC PATCH v2 17/20] arm64: Build the kernel with ORC information madvenka
2022-05-24 0:16 ` [RFC PATCH v2 18/20] arm64: unwinder: Add a reliability check in the unwinder based on ORC madvenka
2022-05-24 0:16 ` [RFC PATCH v2 19/20] arm64: Miscellaneous changes required for enabling livepatch madvenka
2022-07-01 14:16 ` Miroslav Benes
2022-07-01 19:53 ` Madhavan T. Venkataraman
2022-05-24 0:16 ` [RFC PATCH v2 20/20] arm64: Enable livepatch for ARM64 madvenka
2022-05-24 14:24 ` [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation Chen Zhongjin
2022-05-29 15:30 ` Madhavan T. Venkataraman
2022-06-15 12:18 ` Ivan T. Ivanov
2022-06-15 13:37 ` Mark Rutland
2022-06-15 14:18 ` Ivan T. Ivanov
2022-06-15 20:50 ` Madhavan T. Venkataraman
2022-06-15 20:47 ` Madhavan T. Venkataraman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28642a99-0b59-a5dd-aea4-6c1db65c0934@huawei.com \
--to=chenzhongjin@huawei.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jamorris@linux.microsoft.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mark.rutland@arm.com \
--cc=nobuta.keiya@fujitsu.com \
--cc=peterz@infradead.org \
--cc=sjitindarsingh@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).