From: madvenka@linux.microsoft.com To: broonie@kernel.org, mark.rutland@arm.com, jpoimboe@redhat.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, madvenka@linux.microsoft.com Subject: [RFC PATCH v2 5/8] arm64: Detect an FTRACE frame and mark a stack trace unreliable Date: Mon, 15 Mar 2021 11:57:57 -0500 [thread overview] Message-ID: <20210315165800.5948-6-madvenka@linux.microsoft.com> (raw) In-Reply-To: <20210315165800.5948-1-madvenka@linux.microsoft.com> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated for a function, the ftrace infrastructure is called for the function at the very beginning. Ftrace creates two frames: - One for the traced function - One for the caller of the traced function That gives a reliable stack trace while executing in the ftrace infrastructure code. When ftrace returns to the traced function, the frames are popped and everything is back to normal. However, in cases like live patch, execution is redirected to a different function when ftrace returns. A stack trace taken while still in the ftrace infrastructure code will not show the target function. The target function is the real function that we want to track. So, if an FTRACE frame is detected on the stack, just mark the stack trace as unreliable. Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com> --- arch/arm64/kernel/entry-ftrace.S | 2 ++ arch/arm64/kernel/stacktrace.c | 33 ++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S index b3e4f9a088b1..1ec8c5180fc0 100644 --- a/arch/arm64/kernel/entry-ftrace.S +++ b/arch/arm64/kernel/entry-ftrace.S @@ -74,6 +74,8 @@ /* Create our frame record within pt_regs. */ stp x29, x30, [sp, #S_STACKFRAME] add x29, sp, #S_STACKFRAME + ldr w17, =FTRACE_FRAME + str w17, [sp, #S_FRAME_TYPE] .endm SYM_CODE_START(ftrace_regs_caller) diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index 6ae103326f7b..594806a0c225 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -23,6 +23,7 @@ static void check_if_reliable(unsigned long fp, struct stackframe *frame, { struct pt_regs *regs; unsigned long regs_start, regs_end; + unsigned long caller_fp; /* * If the stack trace has already been marked unreliable, just @@ -68,6 +69,38 @@ static void check_if_reliable(unsigned long fp, struct stackframe *frame, frame->reliable = false; return; } + +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS + /* + * When tracing is active for a function, the ftrace code is called + * from the function even before the frame pointer prolog and + * epilog. ftrace creates a pt_regs structure on the stack to save + * register state. + * + * In addition, ftrace sets up two stack frames and chains them + * with other frames on the stack. One frame is pt_regs->stackframe + * that is for the traced function. The other frame is set up right + * after the pt_regs structure and it is for the caller of the + * traced function. This is done to ensure a proper stack trace. + * + * If the ftrace code returns to the traced function, then all is + * fine. But if it transfers control to a different function (like + * in livepatch), then a stack walk performed while still in the + * ftrace code will not find the target function. + * + * So, mark the stack trace as unreliable if an ftrace frame is + * detected. + */ + if (regs->frame_type == FTRACE_FRAME && frame->fp == regs_end && + frame->fp < info->high) { + /* Check the traced function's caller's frame. */ + caller_fp = READ_ONCE_NOCHECK(*(unsigned long *)(frame->fp)); + if (caller_fp == regs->regs[29]) { + frame->reliable = false; + return; + } + } +#endif } /* -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: madvenka@linux.microsoft.com To: broonie@kernel.org, mark.rutland@arm.com, jpoimboe@redhat.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, madvenka@linux.microsoft.com Subject: [RFC PATCH v2 5/8] arm64: Detect an FTRACE frame and mark a stack trace unreliable Date: Mon, 15 Mar 2021 11:57:57 -0500 [thread overview] Message-ID: <20210315165800.5948-6-madvenka@linux.microsoft.com> (raw) In-Reply-To: <20210315165800.5948-1-madvenka@linux.microsoft.com> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated for a function, the ftrace infrastructure is called for the function at the very beginning. Ftrace creates two frames: - One for the traced function - One for the caller of the traced function That gives a reliable stack trace while executing in the ftrace infrastructure code. When ftrace returns to the traced function, the frames are popped and everything is back to normal. However, in cases like live patch, execution is redirected to a different function when ftrace returns. A stack trace taken while still in the ftrace infrastructure code will not show the target function. The target function is the real function that we want to track. So, if an FTRACE frame is detected on the stack, just mark the stack trace as unreliable. Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com> --- arch/arm64/kernel/entry-ftrace.S | 2 ++ arch/arm64/kernel/stacktrace.c | 33 ++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S index b3e4f9a088b1..1ec8c5180fc0 100644 --- a/arch/arm64/kernel/entry-ftrace.S +++ b/arch/arm64/kernel/entry-ftrace.S @@ -74,6 +74,8 @@ /* Create our frame record within pt_regs. */ stp x29, x30, [sp, #S_STACKFRAME] add x29, sp, #S_STACKFRAME + ldr w17, =FTRACE_FRAME + str w17, [sp, #S_FRAME_TYPE] .endm SYM_CODE_START(ftrace_regs_caller) diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index 6ae103326f7b..594806a0c225 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -23,6 +23,7 @@ static void check_if_reliable(unsigned long fp, struct stackframe *frame, { struct pt_regs *regs; unsigned long regs_start, regs_end; + unsigned long caller_fp; /* * If the stack trace has already been marked unreliable, just @@ -68,6 +69,38 @@ static void check_if_reliable(unsigned long fp, struct stackframe *frame, frame->reliable = false; return; } + +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS + /* + * When tracing is active for a function, the ftrace code is called + * from the function even before the frame pointer prolog and + * epilog. ftrace creates a pt_regs structure on the stack to save + * register state. + * + * In addition, ftrace sets up two stack frames and chains them + * with other frames on the stack. One frame is pt_regs->stackframe + * that is for the traced function. The other frame is set up right + * after the pt_regs structure and it is for the caller of the + * traced function. This is done to ensure a proper stack trace. + * + * If the ftrace code returns to the traced function, then all is + * fine. But if it transfers control to a different function (like + * in livepatch), then a stack walk performed while still in the + * ftrace code will not find the target function. + * + * So, mark the stack trace as unreliable if an ftrace frame is + * detected. + */ + if (regs->frame_type == FTRACE_FRAME && frame->fp == regs_end && + frame->fp < info->high) { + /* Check the traced function's caller's frame. */ + caller_fp = READ_ONCE_NOCHECK(*(unsigned long *)(frame->fp)); + if (caller_fp == regs->regs[29]) { + frame->reliable = false; + return; + } + } +#endif } /* -- 2.25.1 _______________________________________________ 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:[~2021-03-15 16:59 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <5997dfe8d261a3a543667b83c902883c1e4bd270> 2021-03-15 16:57 ` [RFC PATCH v2 0/8] arm64: Implement reliable stack trace madvenka 2021-03-15 16:57 ` madvenka 2021-03-15 16:57 ` [RFC PATCH v2 1/8] arm64: Implement stack trace termination record madvenka 2021-03-15 16:57 ` madvenka 2021-03-18 15:09 ` Mark Brown 2021-03-18 15:09 ` Mark Brown 2021-03-18 20:26 ` Madhavan T. Venkataraman 2021-03-18 20:26 ` Madhavan T. Venkataraman 2021-03-19 12:30 ` Mark Brown 2021-03-19 12:30 ` Mark Brown 2021-03-19 14:29 ` Madhavan T. Venkataraman 2021-03-19 14:29 ` Madhavan T. Venkataraman 2021-03-19 18:19 ` Madhavan T. Venkataraman 2021-03-19 18:19 ` Madhavan T. Venkataraman 2021-03-19 22:03 ` Madhavan T. Venkataraman 2021-03-19 22:03 ` Madhavan T. Venkataraman 2021-03-23 10:24 ` Mark Rutland 2021-03-23 10:24 ` Mark Rutland 2021-03-23 12:39 ` Madhavan T. Venkataraman 2021-03-23 12:39 ` Madhavan T. Venkataraman 2021-03-15 16:57 ` [RFC PATCH v2 2/8] arm64: Implement frame types madvenka 2021-03-15 16:57 ` madvenka 2021-03-18 17:40 ` Mark Brown 2021-03-18 17:40 ` Mark Brown 2021-03-18 22:22 ` Madhavan T. Venkataraman 2021-03-18 22:22 ` Madhavan T. Venkataraman 2021-03-19 13:22 ` Mark Brown 2021-03-19 13:22 ` Mark Brown 2021-03-19 14:40 ` Madhavan T. Venkataraman 2021-03-19 14:40 ` Madhavan T. Venkataraman 2021-03-19 15:02 ` Madhavan T. Venkataraman 2021-03-19 15:02 ` Madhavan T. Venkataraman 2021-03-19 16:20 ` Mark Brown 2021-03-19 16:20 ` Mark Brown 2021-03-19 16:27 ` Madhavan T. Venkataraman 2021-03-19 16:27 ` Madhavan T. Venkataraman 2021-03-23 10:34 ` Mark Rutland 2021-03-23 10:34 ` Mark Rutland 2021-03-15 16:57 ` [RFC PATCH v2 3/8] arm64: Terminate the stack trace at TASK_FRAME and EL0_FRAME madvenka 2021-03-15 16:57 ` madvenka 2021-03-18 18:26 ` Mark Brown 2021-03-18 18:26 ` Mark Brown 2021-03-18 20:29 ` Madhavan T. Venkataraman 2021-03-18 20:29 ` Madhavan T. Venkataraman 2021-03-23 10:36 ` Mark Rutland 2021-03-23 10:36 ` Mark Rutland 2021-03-23 12:40 ` Madhavan T. Venkataraman 2021-03-23 12:40 ` Madhavan T. Venkataraman 2021-03-15 16:57 ` [RFC PATCH v2 4/8] arm64: Detect an EL1 exception frame and mark a stack trace unreliable madvenka 2021-03-15 16:57 ` madvenka 2021-03-23 10:42 ` Mark Rutland 2021-03-23 10:42 ` Mark Rutland 2021-03-23 12:46 ` Madhavan T. Venkataraman 2021-03-23 12:46 ` Madhavan T. Venkataraman 2021-03-23 13:04 ` Mark Rutland 2021-03-23 13:04 ` Mark Rutland 2021-03-23 13:31 ` Madhavan T. Venkataraman 2021-03-23 13:31 ` Madhavan T. Venkataraman 2021-03-23 14:33 ` Mark Rutland 2021-03-23 14:33 ` Mark Rutland 2021-03-23 15:22 ` Madhavan T. Venkataraman 2021-03-23 15:22 ` Madhavan T. Venkataraman 2021-03-15 16:57 ` madvenka [this message] 2021-03-15 16:57 ` [RFC PATCH v2 5/8] arm64: Detect an FTRACE " madvenka 2021-03-23 10:51 ` Mark Rutland 2021-03-23 10:51 ` Mark Rutland 2021-03-23 12:56 ` Madhavan T. Venkataraman 2021-03-23 12:56 ` Madhavan T. Venkataraman 2021-03-23 13:36 ` Mark Rutland 2021-03-23 13:36 ` Mark Rutland 2021-03-23 13:38 ` Madhavan T. Venkataraman 2021-03-23 13:38 ` Madhavan T. Venkataraman 2021-03-23 14:15 ` Madhavan T. Venkataraman 2021-03-23 14:15 ` Madhavan T. Venkataraman 2021-03-23 14:57 ` Mark Rutland 2021-03-23 14:57 ` Mark Rutland 2021-03-23 15:26 ` Madhavan T. Venkataraman 2021-03-23 15:26 ` Madhavan T. Venkataraman 2021-03-23 16:20 ` Madhavan T. Venkataraman 2021-03-23 16:20 ` Madhavan T. Venkataraman 2021-03-23 17:02 ` Mark Rutland 2021-03-23 17:02 ` Mark Rutland 2021-03-23 17:23 ` Madhavan T. Venkataraman 2021-03-23 17:23 ` Madhavan T. Venkataraman 2021-03-23 17:27 ` Madhavan T. Venkataraman 2021-03-23 17:27 ` Madhavan T. Venkataraman 2021-03-23 18:27 ` Mark Brown 2021-03-23 18:27 ` Mark Brown 2021-03-23 20:23 ` Madhavan T. Venkataraman 2021-03-23 20:23 ` Madhavan T. Venkataraman 2021-03-23 18:30 ` Mark Rutland 2021-03-23 18:30 ` Mark Rutland 2021-03-23 20:24 ` Madhavan T. Venkataraman 2021-03-23 20:24 ` Madhavan T. Venkataraman 2021-03-23 21:04 ` Madhavan T. Venkataraman 2021-03-23 21:04 ` Madhavan T. Venkataraman 2021-03-23 16:48 ` Mark Rutland 2021-03-23 16:48 ` Mark Rutland 2021-03-23 16:53 ` Madhavan T. Venkataraman 2021-03-23 16:53 ` Madhavan T. Venkataraman 2021-03-23 17:09 ` Mark Rutland 2021-03-23 17:09 ` Mark Rutland 2021-03-15 16:57 ` [RFC PATCH v2 6/8] arm64: Check the return PC of every stack frame madvenka 2021-03-15 16:57 ` madvenka 2021-03-15 16:57 ` [RFC PATCH v2 7/8] arm64: Detect kretprobed functions in stack trace madvenka 2021-03-15 16:57 ` madvenka 2021-03-15 16:58 ` [RFC PATCH v2 8/8] arm64: Implement arch_stack_walk_reliable() madvenka 2021-03-15 16:58 ` madvenka 2021-03-15 19:01 ` [RFC PATCH v2 0/8] arm64: Implement reliable stack trace Madhavan T. Venkataraman 2021-03-15 19:01 ` 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=20210315165800.5948-6-madvenka@linux.microsoft.com \ --to=madvenka@linux.microsoft.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=jpoimboe@redhat.com \ --cc=jthierry@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=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.