Date: Fri, 13 Apr 2018 20:44:48 +0300 From: Konstantin Belousov <kib@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r332454 - in head/sys: amd64/amd64 amd64/ia32 amd64/linux amd64/linux32 i386/i386 Message-ID: <20180413174448.GA1774@kib.kiev.ua> In-Reply-To: <6635699.GyEHu4i8EZ@ralph.baldwin.cx> References: <201804122043.w3CKhdFF041945@repo.freebsd.org> <6635699.GyEHu4i8EZ@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180413174448.GA1774>