On Fri, Apr 13, 2018 at 10:30:39AM -0700, John Baldwin wrote:
> On Thursday, April 12, 2018 08:43:39 PM Konstantin Belousov wrote:
> > Author: kib
> > Date: Thu Apr 12 20:43:39 2018
> > New Revision: 332454
> > URL: https://svnweb.freebsd.org/changeset/base/332454
> >
> > Log:
> > Fix PSL_T inheritance on exec for x86.
> >
> > The miscellaneous x86 sysent->sv_setregs() implementations tried to
> > migrate PSL_T from the previous program to the new executed one, but
> > they evaluated regs->tf_eflags after the whole regs structure was
> > bzeroed. Make this functional by saving PSL_T value before zeroing.
> >
> > Note that if the debugger is not attached, executing the first
> > instruction in the new program with PSL_T set results in SIGTRAP, and
> > since all intercepted signals are reset to default dispostion on
> > exec(2), this means that non-debugged process gets killed immediately
> > if PSL_T is inherited. In particular, since suid images drop
> > P_TRACED, attempt to set PSL_T for execution of such program would
> > kill the process.
> >
> > Another issue with userspace PSL_T handling is that it is reset by
> > trap(). It is reasonable to clear PSL_T when entering SIGTRAP
> > handler, to allow the signal to be handled without recursion or
> > delivery of blocked fault. But it is not reasonable to return back to
> > the normal flow with PSL_T cleared. This is too late to change, I
> > think.
>
> Hmm, I had wanted to write an explicit test for this in ptrace_test.c so that
> we could ensure other architectures that support hardware stepping (like
> aarch64) use matching semantics. It wasn't clear to me if clearing PSL_T on
> exec() isn't actually more correct. Exec will report a PL_FLAG_EXEC ptrace
> stop and the debugger can PT_STEP from that stop if it wants to continue
> stepping post-exec.
>
> The trap() case is indeed interesting, but I think the concern you raise is
> largely mitigated by having the debugger simple re-enable stepping after
> resuming from the event reported from trapsignal(). OTOH, we explicitly
> clear PSL_T in sendsig() so that signal handlers don't step. I feel like we
> probably should not do this for traced processes as this fix single stepping
> in a debugger to properly report a step for the start of a signal handler.
> FWIW, Linux single steps into signal handlers instead of over them as we
> currently do. (I have even some thoughts on how to fix stepping for
> architectures like MIPS that do software stepping by letting the debugger
> enable a "report a step for first signal instruction" mode while it is
> stepping a thread and then reporting an explicit SIGTRAP ptracestop()
> during sendsig.)
There is https://reviews.freebsd.org/D15054 where I added you as reviewer.
If you consider it the right thing to do, I can easily add a quirk to stop
clearing PSL_T in sendsig()s.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
