Re: [discuss] Re: [PATCH 3/3] reliable stack trace support (i386)

From: Andi Kleen
Date: Tue May 16 2006 - 11:21:48 EST



> > +static inline void
> > +arch_unw_init_blocked(struct unwind_frame_info *info)
> > +{
> > + memset(&info->regs, 0, sizeof(info->regs));
> > + info->regs.eip = info->task->thread.eip;
> > + info->regs.xcs = __KERNEL_CS;
> > + __get_user(info->regs.ebp, (long *)info->task->thread.esp);
> > + info->regs.esp = info->task->thread.esp;
> > + info->regs.xss = __KERNEL_DS;
> > + info->regs.xds = __USER_DS;
> > + info->regs.xes = __USER_DS;
>
> hm, arent you using this from within show_trace()? In that case we
> shouldnt do a __get_user() i think, we might be in an arbitrary context

Should be ok. We already do this in some parts of oopsing and the page fault handler
can handle it as long as there is an exception entry (which is there for this case)

> ...
>
> > +static inline int
> > +arch_unw_user_mode(const struct unwind_frame_info *info)
> > +{
> > +#if 0 /* This can only work when selector register and EFLAGS saves/restores
> > + are properly annotated (and tracked in UNW_REGISTER_INFO). */
> > + return user_mode_vm(&info->regs);
> > +#else
> > + return info->regs.eip < PAGE_OFFSET;
> > +#endif
>
> same here as for x86_64: is this condition safe? Userspace can provoke
> an EIP of >= PAGE_OFFSET by for example jumping to the vsyscall page.

Good point, it's probably not. Especially since we already have a user_mode() macro

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/