From owner-svn-src-all@freebsd.org Fri Apr 13 17:45:06 2018 Return-Path: Delivered-To: svn-src-all@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 DE05FF9A14B; Fri, 13 Apr 2018 17:45:05 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1947A48A; Fri, 13 Apr 2018 17:45:05 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3DHimxw058714 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Apr 2018 20:44:51 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3DHimxw058714 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3DHimj3058713; Fri, 13 Apr 2018 20:44:48 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Fri, 13 Apr 2018 20:44:48 +0300 From: Konstantin Belousov To: John Baldwin 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> References: <201804122043.w3CKhdFF041945@repo.freebsd.org> <6635699.GyEHu4i8EZ@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6635699.GyEHu4i8EZ@ralph.baldwin.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 17:45:06 -0000 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.