From owner-svn-src-head@freebsd.org Fri Apr 13 17:36:47 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F01E9F9976A; Fri, 13 Apr 2018 17:36:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8992079D72; Fri, 13 Apr 2018 17:36:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 7234610AFD2; Fri, 13 Apr 2018 13:36:45 -0400 (EDT) From: John Baldwin To: Konstantin Belousov 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 Date: Fri, 13 Apr 2018 10:30:39 -0700 Message-ID: <6635699.GyEHu4i8EZ@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <201804122043.w3CKhdFF041945@repo.freebsd.org> References: <201804122043.w3CKhdFF041945@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 13 Apr 2018 13:36:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 17:36:47 -0000 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.) -- John Baldwin