From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: Chen Zhongjin <chenzhongjin@huawei.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: Sun, 29 May 2022 10:18:00 -0500 [thread overview] Message-ID: <ad2368a3-17fd-ad7e-95e8-0b7fa9b59fec@linux.microsoft.com> (raw) In-Reply-To: <767e814c-b3cc-73a1-d283-82dbc0287cde@huawei.com> 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. Madhavan
WARNING: multiple messages have this Message-ID (diff)
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: Chen Zhongjin <chenzhongjin@huawei.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: Sun, 29 May 2022 10:18:00 -0500 [thread overview] Message-ID: <ad2368a3-17fd-ad7e-95e8-0b7fa9b59fec@linux.microsoft.com> (raw) In-Reply-To: <767e814c-b3cc-73a1-d283-82dbc0287cde@huawei.com> 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. Madhavan _______________________________________________ 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-29 15:18 UTC|newest] Thread overview: 80+ 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 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 01/20] objtool: Reorganize CFI code madvenka 2022-05-24 0:16 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 02/20] objtool: Reorganize instruction-related code madvenka 2022-05-24 0:16 ` 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 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 04/20] objtool: Reorganize Unwind hint code madvenka 2022-05-24 0:16 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 05/20] objtool: Reorganize ORC types madvenka 2022-05-24 0:16 ` madvenka 2022-05-24 14:27 ` Chen Zhongjin 2022-05-24 14:27 ` Chen Zhongjin 2022-05-29 15:36 ` Madhavan T. Venkataraman 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 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 07/20] objtool: Reorganize ORC kernel code madvenka 2022-05-24 0:16 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 08/20] objtool: arm64: Implement decoder for FP validation madvenka 2022-05-24 0:16 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 09/20] objtool: arm64: Implement command to invoke the decoder madvenka 2022-05-24 0:16 ` madvenka 2022-05-24 14:09 ` Mark Brown 2022-05-24 14:09 ` Mark Brown 2022-05-29 14:49 ` Madhavan T. Venkataraman 2022-05-29 14:49 ` Madhavan T. Venkataraman 2022-05-30 7:51 ` Peter Zijlstra 2022-05-30 7:51 ` Peter Zijlstra 2022-06-01 22:45 ` Madhavan T. Venkataraman 2022-06-01 22:45 ` Madhavan T. Venkataraman 2022-06-07 18:13 ` 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 ` 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 0:16 ` madvenka 2022-05-24 13:45 ` Chen Zhongjin 2022-05-24 13:45 ` Chen Zhongjin 2022-05-29 15:18 ` Madhavan T. Venkataraman [this message] 2022-05-29 15:18 ` Madhavan T. Venkataraman 2022-05-30 1:44 ` Chen Zhongjin 2022-05-30 1:44 ` Chen Zhongjin 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 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 13/20] objtool: arm64: Dump ORC data present in " madvenka 2022-05-24 0:16 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 14/20] objtool: arm64: Add unwind hint support madvenka 2022-05-24 0:16 ` 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 ` 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 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 17/20] arm64: Build the kernel with ORC information madvenka 2022-05-24 0:16 ` 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 ` madvenka 2022-05-24 0:16 ` [RFC PATCH v2 19/20] arm64: Miscellaneous changes required for enabling livepatch madvenka 2022-05-24 0:16 ` madvenka 2022-07-01 14:16 ` Miroslav Benes 2022-07-01 14:16 ` Miroslav Benes 2022-07-01 19:53 ` Madhavan T. Venkataraman 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 0:16 ` madvenka 2022-05-24 14:24 ` [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation Chen Zhongjin 2022-05-24 14:24 ` Chen Zhongjin 2022-05-29 15:30 ` Madhavan T. Venkataraman 2022-05-29 15:30 ` Madhavan T. Venkataraman 2022-06-15 12:18 ` Ivan T. Ivanov 2022-06-15 12:18 ` Ivan T. Ivanov 2022-06-15 13:37 ` Mark Rutland 2022-06-15 13:37 ` Mark Rutland 2022-06-15 14:18 ` Ivan T. Ivanov 2022-06-15 14:18 ` Ivan T. Ivanov 2022-06-15 20:50 ` Madhavan T. Venkataraman 2022-06-15 20:50 ` Madhavan T. Venkataraman 2022-06-15 20:47 ` 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=ad2368a3-17fd-ad7e-95e8-0b7fa9b59fec@linux.microsoft.com \ --to=madvenka@linux.microsoft.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=chenzhongjin@huawei.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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.