| Message ID | 1524221179-19473-4-git-send-email-Dave.Martin@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Apr 20, 2018 at 11:46:19AM +0100, Dave Martin wrote: > In the event of stack corruption, backtraces may loop indefinitely > or wander off into memory that is not a valid stack for the context > being backtraced. > > This patch makes backtracing more robust against stack corruption, > by taking two things into account: > > * while staying on the same stack, the frame address must strictly > increase from each frame to its ancestor; > > * when transitioning to another stack, the set of valid stacks for > the context forms a strict hierarchy (e.g., a frame on the task > stack cannot have an ancestor frame on the IRQ stack because > task context cannot preempt IRQ handlers etc.) > > on_accessible_stack() is converted to a more expressive helper > identify_stack() that also tells the caller _which_ stack the task > appears to be on. The stack identifier is represented by an enum > sorted into the correct order for checking stack transition > validity by a simple numeric comparison. A field stack_id is added > to struct stackframe to track the result of this for the frame. > > Now that it is easy to check whether two successive frames are on > the same stack, it is easy to add a check for strictly increasing > frame address, to avoid looping around the same stack. > > Now that frames can be mapped to a strict lexical order on the > stack id and frame address, forward progress should be guaranteed. > > Backtracing now terminates whenever the next frame violates this > order, with kernel entry (with fp == 0 && pc == 0) as a special > case of this. > > Reported-by: Ji Zhang <ji.zhang@mediatek.com> > Signed-off-by: Dave Martin <Dave.Martin@arm.com> > > --- > > The assumption that we can place the possible stacks (task, IRQ, > overflow, SDEI) in a strict order is based on a quick review of > entry.S, but I may have this wrong... in which case the approach > proposed in this patch may need tweaking (or may not work at all). We have a partial ordering where we can transition between stacks: task -> irq -> {overflow,sdei} The only problem that I'm aware of is that you could go either way: overflow -> sdei sdei -> overflow In either case, there's a fatal error, and it would be very nice to get the most reliable stacktrace possible rather than terminating early. The only way I'd thought to avoid that was to keep track of the last SP we saw per-stack to avoid a lexical ordering, e.g. struct stackframe { ... /* assume we init these to 0 before unwinding */ unsigned long last_task_fp; unsigned long last_irq_fp; unsigned long last_ovf_fp; unsigned long last_sdei_fp; }; ... and corresponding when we unwind a frame, do something like: if (on_task_stack(task, sp) { if (sp < frame->last_task_fp) <fail> frame->last_task_fp = sp; } else if (on_irq_stack(sp)) { if (sp < frame->last_irq_fp) <fail> frame->last_irq_fp = sp; } else (...) { ... } Thanks, Mark.
On Fri, Apr 20, 2018 at 11:58:14AM +0100, Mark Rutland wrote: > On Fri, Apr 20, 2018 at 11:46:19AM +0100, Dave Martin wrote: > > In the event of stack corruption, backtraces may loop indefinitely > > or wander off into memory that is not a valid stack for the context > > being backtraced. > > > > This patch makes backtracing more robust against stack corruption, > > by taking two things into account: > > > > * while staying on the same stack, the frame address must strictly > > increase from each frame to its ancestor; > > > > * when transitioning to another stack, the set of valid stacks for > > the context forms a strict hierarchy (e.g., a frame on the task > > stack cannot have an ancestor frame on the IRQ stack because > > task context cannot preempt IRQ handlers etc.) > > > > on_accessible_stack() is converted to a more expressive helper > > identify_stack() that also tells the caller _which_ stack the task > > appears to be on. The stack identifier is represented by an enum > > sorted into the correct order for checking stack transition > > validity by a simple numeric comparison. A field stack_id is added > > to struct stackframe to track the result of this for the frame. > > > > Now that it is easy to check whether two successive frames are on > > the same stack, it is easy to add a check for strictly increasing > > frame address, to avoid looping around the same stack. > > > > Now that frames can be mapped to a strict lexical order on the > > stack id and frame address, forward progress should be guaranteed. > > > > Backtracing now terminates whenever the next frame violates this > > order, with kernel entry (with fp == 0 && pc == 0) as a special > > case of this. > > > > Reported-by: Ji Zhang <ji.zhang@mediatek.com> > > Signed-off-by: Dave Martin <Dave.Martin@arm.com> > > > > --- > > > > The assumption that we can place the possible stacks (task, IRQ, > > overflow, SDEI) in a strict order is based on a quick review of > > entry.S, but I may have this wrong... in which case the approach > > proposed in this patch may need tweaking (or may not work at all). > > We have a partial ordering where we can transition between stacks: > > task -> irq -> {overflow,sdei} > > The only problem that I'm aware of is that you could go either way: > > overflow -> sdei > sdei -> overflow > In either case, there's a fatal error, and it would be very nice to get > the most reliable stacktrace possible rather than terminating early. Agreed, where we must choose between a possibly-incomplete backtrace or a possibly-incorrect backtrace, we should probably err on the side of completeness. To what extent do we claim to cope with recursive stack overflows? We could get something like task -> overflow -> irq -> overflow -> sdei -> overflow (We can also take a single nested SDE, but if the sdei stack already overflowed I think we're basically dead if that happens here, unless SDEI checks for this and continues on the overflow stack if that happens). > The only way I'd thought to avoid that was to keep track of the last SP > we saw per-stack to avoid a lexical ordering, e.g. > > struct stackframe { > > ... > > /* assume we init these to 0 before unwinding */ > unsigned long last_task_fp; > unsigned long last_irq_fp; > unsigned long last_ovf_fp; > unsigned long last_sdei_fp; > }; But possibly we only need to track ovf and sdei here, unless I'm misunderstanding. If that's right perhaps my approach can be tweaked rather then being completely unusable, but I'll need to have a think. > > ... and corresponding when we unwind a frame, do something like: > > if (on_task_stack(task, sp) { > if (sp < frame->last_task_fp) > <fail> > frame->last_task_fp = sp; > } else if (on_irq_stack(sp)) { > if (sp < frame->last_irq_fp) > <fail> > frame->last_irq_fp = sp; > } else (...) { > ... > } I guess. I think mine is nicer (of course), but also brokener for now... Cheers ---Dave
On Fri, Apr 20, 2018 at 12:19:50PM +0100, Dave Martin wrote: > On Fri, Apr 20, 2018 at 11:58:14AM +0100, Mark Rutland wrote: > > On Fri, Apr 20, 2018 at 11:46:19AM +0100, Dave Martin wrote: > > > The assumption that we can place the possible stacks (task, IRQ, > > > overflow, SDEI) in a strict order is based on a quick review of > > > entry.S, but I may have this wrong... in which case the approach > > > proposed in this patch may need tweaking (or may not work at all). > > > > We have a partial ordering where we can transition between stacks: > > > > task -> irq -> {overflow,sdei} > > > > The only problem that I'm aware of is that you could go either way: > > > > overflow -> sdei > > sdei -> overflow > > > In either case, there's a fatal error, and it would be very nice to get > > the most reliable stacktrace possible rather than terminating early. > > Agreed, where we must choose between a possibly-incomplete backtrace or > a possibly-incorrect backtrace, we should probably err on the side of > completeness. > > To what extent do we claim to cope with recursive stack overflows? We don't claim to handle this at all. If we overflow on the overflow stack, we'll try to reuse the overflow stack, and things go badly. We *could* add a per-cpu flag to say already-overflowed, and go into a WFI loop upon a recursive overflow, but we can't do something reliably fatal in this case. > We could get something like > > task -> overflow -> irq -> overflow -> sdei -> overflow We only transition task -> irq, and not overflow -> irq. In irq_stack_entry, we only transition to the IRQ stack if we're on a task stack, so we can't have overflow -> irq. I believe that the worst case is something like: task -> irq -> overflow -> sdei -> overflow. ... but at that point we're very much dead, and can't reliably unwind past the SDEI stack. We could have flags saying if we've hit a particular stack before, and when transitioning, abort if we've already been on that stack. > (We can also take a single nested SDE, but if the sdei stack already > overflowed I think we're basically dead if that happens here, unless > SDEI checks for this and continues on the overflow stack if that > happens). The overflow handler won't return to the first SDE stack, so that's fatal, but not much worse than taking a regular SDE while on the overflow stack. IIUC to take a nested SDE, the first has to be a normal SDE, and the second a critical SDE. With VMAP_STACK, those use separate stacks, and thus the second SDE shouldn't corrupt the contest of the first. Without VMAP_STACK, the overflow isn't handled reliably anyhow. Thanks, Mark.
diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h index c9bef22..fe97ff1 100644 --- a/arch/arm64/include/asm/stacktrace.h +++ b/arch/arm64/include/asm/stacktrace.h @@ -24,9 +24,26 @@ #include <asm/ptrace.h> #include <asm/sdei.h> +/* + * Set of stacks that a given task may execute on. + * + * This must be sorted so that if entry A appears before entry B, the + * context corresponding to A cannot preempt the context corresponding + * to B. This property is used by the unwinder to verify forward + * progress by means of a numeric comparison on this enum. + */ +enum arm64_stack_id { + ARM64_STACK_NONE, + ARM64_STACK_TASK, + ARM64_STACK_IRQ, + ARM64_STACK_OVERFLOW, + ARM64_STACK_SDEI, +}; + struct stackframe { unsigned long fp; unsigned long pc; + enum arm64_stack_id stack_id; #ifdef CONFIG_FUNCTION_GRAPH_TRACER int graph; #endif @@ -77,21 +94,22 @@ static inline bool on_overflow_stack(unsigned long sp) { return false; } * We can only safely access per-cpu stacks from current in a non-preemptible * context. */ -static inline bool on_accessible_stack(struct task_struct const *tsk, - unsigned long sp) +static enum arm64_stack_id identify_stack(struct task_struct const *tsk, + unsigned long sp) { if (on_task_stack(tsk, sp)) - return true; + return ARM64_STACK_TASK; if (tsk != current || preemptible()) - return false; + goto bad; if (on_irq_stack(sp)) - return true; + return ARM64_STACK_IRQ; if (on_overflow_stack(sp)) - return true; + return ARM64_STACK_OVERFLOW; if (on_sdei_stack(sp)) - return true; + return ARM64_STACK_SDEI; - return false; +bad: + return ARM64_STACK_NONE; } static inline void start_backtrace(struct stackframe *frame, @@ -100,6 +118,7 @@ static inline void start_backtrace(struct stackframe *frame, { frame->fp = fp; frame->pc = pc; + frame->stack_id = identify_stack(tsk, fp); #ifdef CONFIG_FUNCTION_GRAPH_TRACER frame.graph = tsk->curr_ret_stack; #endif diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index d5718a0..518ac57 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -43,6 +43,7 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame) { unsigned long fp = frame->fp; + enum arm64_stack_id stack_id = frame->stack_id; if (fp & 0xf) return -EINVAL; @@ -50,11 +51,12 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame) if (!tsk) tsk = current; - if (!on_accessible_stack(tsk, fp)) + if (stack_id == ARM64_STACK_NONE) return -EINVAL; frame->fp = READ_ONCE_NOCHECK(*(unsigned long *)(fp)); frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8)); + frame->stack_id = identify_stack(tsk, frame->fp); #ifdef CONFIG_FUNCTION_GRAPH_TRACER if (tsk->ret_stack && @@ -75,12 +77,14 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame) #endif /* CONFIG_FUNCTION_GRAPH_TRACER */ /* - * Frames created upon entry from EL0 have NULL FP and PC values, so - * don't bother reporting these. Frames created by __noreturn functions - * might have a valid FP even if PC is bogus, so only terminate where - * both are NULL. + * Terminate when the next frame isn't on any valid stack for + * tsk. As a special case, frames created upon entry from EL0 + * have NULL FP and PC values, so will terminate here also. + * Frames created by __noreturn functions might have a valid FP + * even if PC is bogus, so only terminate where FP is invalid. */ - if (!frame->fp && !frame->pc) + if (frame->stack_id > stack_id || + (frame->stack_id == stack_id && frame->fp <= fp)) return -EINVAL; return 0;
In the event of stack corruption, backtraces may loop indefinitely or wander off into memory that is not a valid stack for the context being backtraced. This patch makes backtracing more robust against stack corruption, by taking two things into account: * while staying on the same stack, the frame address must strictly increase from each frame to its ancestor; * when transitioning to another stack, the set of valid stacks for the context forms a strict hierarchy (e.g., a frame on the task stack cannot have an ancestor frame on the IRQ stack because task context cannot preempt IRQ handlers etc.) on_accessible_stack() is converted to a more expressive helper identify_stack() that also tells the caller _which_ stack the task appears to be on. The stack identifier is represented by an enum sorted into the correct order for checking stack transition validity by a simple numeric comparison. A field stack_id is added to struct stackframe to track the result of this for the frame. Now that it is easy to check whether two successive frames are on the same stack, it is easy to add a check for strictly increasing frame address, to avoid looping around the same stack. Now that frames can be mapped to a strict lexical order on the stack id and frame address, forward progress should be guaranteed. Backtracing now terminates whenever the next frame violates this order, with kernel entry (with fp == 0 && pc == 0) as a special case of this. Reported-by: Ji Zhang <ji.zhang@mediatek.com> Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- The assumption that we can place the possible stacks (task, IRQ, overflow, SDEI) in a strict order is based on a quick review of entry.S, but I may have this wrong... in which case the approach proposed in this patch may need tweaking (or may not work at all). --- arch/arm64/include/asm/stacktrace.h | 35 +++++++++++++++++++++++++++-------- arch/arm64/kernel/stacktrace.c | 16 ++++++++++------ 2 files changed, 37 insertions(+), 14 deletions(-)