From: Dave Martin <Dave.Martin@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: catalin.marinas@arm.com, tengfeif@codeaurora.org,
will.deacon@arm.com, james.morse@arm.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/3] arm64: stacktrace: better handle corrupted stacks
Date: Fri, 21 Jun 2019 17:37:21 +0100 [thread overview]
Message-ID: <20190621163721.GF2790@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20190606125402.10229-4-mark.rutland@arm.com>
On Thu, Jun 06, 2019 at 01:54:02PM +0100, Mark Rutland wrote:
> The arm64 stacktrace code is careful to only dereference frame records
> in valid stack ranges, ensuring that a corrupted frame record won't
> result in a faulting access.
>
> However, it's still possible for corrupt frame records to result in
> infinite loops in the stacktrace code, which is also undesirable.
>
> This patch ensures that we complete a stacktrace in finite time, by
> keeping track of which stacks we have already completed unwinding, and
> verifying that if the next frame record is on the same stack, it is at a
> higher address.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Tengfei Fan <tengfeif@codeaurora.org>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/stacktrace.h | 34 ++++++++++++++++++++++++++--------
> arch/arm64/kernel/process.c | 2 +-
> arch/arm64/kernel/stacktrace.c | 16 +++++++++++++++-
> arch/arm64/kernel/time.c | 2 +-
> arch/arm64/kernel/traps.c | 4 ++--
> 5 files changed, 45 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
> index 18f90bf1385c..4ebf8a8997b0 100644
> --- a/arch/arm64/include/asm/stacktrace.h
> +++ b/arch/arm64/include/asm/stacktrace.h
> @@ -19,19 +19,12 @@
> #include <linux/percpu.h>
> #include <linux/sched.h>
> #include <linux/sched/task_stack.h>
> +#include <linux/types.h>
>
> #include <asm/memory.h>
> #include <asm/ptrace.h>
> #include <asm/sdei.h>
>
> -struct stackframe {
> - unsigned long fp;
> - unsigned long pc;
> -#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> - int graph;
> -#endif
> -};
> -
> enum stack_type {
> STACK_TYPE_UNKNOWN,
> STACK_TYPE_TASK,
> @@ -39,6 +32,7 @@ enum stack_type {
> STACK_TYPE_OVERFLOW,
> STACK_TYPE_SDEI_NORMAL,
> STACK_TYPE_SDEI_CRITICAL,
> + __NR_STACK_TYPES
The number of stack types is actually 1 less than this, and the zeroth
bit in stacks_done doesn't get used if we use this enum as an index.
Would STACK_TYPE_UNKNOWN = 0 fix this, or would that break something
elsewhere?
> };
>
> struct stack_info {
> @@ -47,6 +41,16 @@ struct stack_info {
> enum stack_type type;
> };
>
> +struct stackframe {
> + unsigned long fp;
> + unsigned long pc;
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + int graph;
> +#endif
> + DECLARE_BITMAP(stacks_done, __NR_STACK_TYPES);
> + enum stack_type stack_current;
> +};
> +
> extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
> extern void walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
> int (*fn)(struct stackframe *, void *), void *data);
> @@ -128,6 +132,9 @@ static inline bool on_accessible_stack(const struct task_struct *tsk,
> unsigned long sp,
> struct stack_info *info)
> {
> + if (info)
> + info->type = STACK_TYPE_UNKNOWN;
> +
> if (on_task_stack(tsk, sp, info))
> return true;
> if (tsk != current || preemptible())
> @@ -143,13 +150,24 @@ static inline bool on_accessible_stack(const struct task_struct *tsk,
> }
>
> static inline void start_backtrace(struct stackframe *frame,
> + struct task_struct *tsk,
> unsigned long fp, unsigned long pc)
> {
> + struct stack_info info;
> +
> frame->fp = fp;
> frame->pc = pc;
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> frame->graph = 0;
> #endif
> + bitmap_zero(frame->stacks_done, __NR_STACK_TYPES);
> +
> + /*
> + * We need to prime stack_current for the first unwind, but we can
> + * ignore the accessibility until the unwind occurs.
> + */
> + on_accessible_stack(tsk, fp, &info);
> + frame->stack_current = info.type;
> }
>
> #endif /* __ASM_STACKTRACE_H */
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 122d88fccd13..ba9441982573 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -509,7 +509,7 @@ unsigned long get_wchan(struct task_struct *p)
> if (!stack_page)
> return 0;
>
> - start_backtrace(&frame, thread_saved_fp(p), thread_saved_pc(p));
> + start_backtrace(&frame, p, thread_saved_fp(p), thread_saved_pc(p));
> do {
> if (unwind_frame(p, &frame))
> goto out;
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index b00ec7d483d1..1c45b33c7474 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -43,6 +43,8 @@
> int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
> {
> unsigned long fp = frame->fp;
> + bool changed_stack = false;
> + struct stack_info info;
>
> if (fp & 0xf)
> return -EINVAL;
> @@ -50,12 +52,24 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
> if (!tsk)
> tsk = current;
>
> - if (!on_accessible_stack(tsk, fp, NULL))
> + if (!on_accessible_stack(tsk, fp, &info))
> return -EINVAL;
>
> + if (test_bit(info.type, frame->stacks_done))
> + return -EINVAL;
Doesn't this fire when we unwind a sequence of frames on the same stack
(i.e., the common case)?
I may be missing something obvious here.
> +
> + if (frame->stack_current != info.type) {
> + set_bit(frame->stack_current, frame->stacks_done);
Oh, right, stacks_done is the set of stacks we have been on, excluding
the current one? If so, a comment somewhere explaining that, or some
more explicit name, like "past_stacks" might make sense.
> + frame->stack_current = info.type;
> + changed_stack = true;
> + }
> +
> frame->fp = READ_ONCE_NOCHECK(*(unsigned long *)(fp));
> frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8));
>
> + if (!changed_stack && frame->fp <= fp)
> + return -EINVAL;
> +
[...]
Otherwise, seems to make sense.
Cheers
---Dave
_______________________________________________
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:[~2019-06-21 16:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 12:53 [PATCH 0/3] arm64: stacktrace: improve robustness Mark Rutland
2019-06-06 12:54 ` [PATCH 1/3] arm64: stacktrace: Constify stacktrace.h functions Mark Rutland
2019-06-06 12:54 ` [PATCH 2/3] arm64: stacktrace: Factor out backtrace initialisation Mark Rutland
2019-06-21 15:50 ` Dave Martin
2019-06-28 11:27 ` Mark Rutland
2019-06-06 12:54 ` [PATCH 3/3] arm64: stacktrace: better handle corrupted stacks Mark Rutland
2019-06-21 16:37 ` Dave Martin [this message]
2019-06-28 11:32 ` Mark Rutland
2019-06-24 11:34 ` James Morse
2019-06-25 10:28 ` James Morse
2019-06-27 16:24 ` James Morse
2019-06-28 11:15 ` Dave Martin
2019-06-28 13:02 ` Mark Rutland
2019-07-01 10:48 ` Dave Martin
2019-07-01 11:22 ` Mark Rutland
2019-06-28 15:35 ` Mark Rutland
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=20190621163721.GF2790@e103592.cambridge.arm.com \
--to=dave.martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=tengfeif@codeaurora.org \
--cc=will.deacon@arm.com \
/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).