lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 9 Sep 2011 22:03:10 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Pedro Alves <pedro@...esourcery.com>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data'

On Friday 09 September 2011 19:09, Pedro Alves wrote:
> > This would be a _very_ minor improvement, so tiny it's not worth
> > bothering with. Let me show you the real-world code (part of strace
> > source) which skips over unneeded PTRACE_EVENT_EXEC:
> > 
> >                 if ((status >> 16) != 0)
> >                         /* Ptrace event (we ignore all of them for now) */
> >                         goto restart_tracee_with_sig_0;
> > 
> > Yes. That is all.
> > It probably compiles into just two assembly instructions.
> 
> WTH?  I'm talking about _not forcing the tracee to stop_.  Let
> me repeat.  NOT FORCING THE TRACEE TO STOP.

No need to shout.

execve is such a rare syscall the one extra stop on it is not
going to be a problem.

> And about not needing to handle the magic unadorned SIGTRAP.
> The magic unadorned post-exec SIGTRAP does not have `status & 0xff00'
> set, it is not a ptrace event!

What SIGTRAP? With PTRACE_O_TRACEEXEC, there is no SIGTRAP.

> If we don't disable the magic SIGTRAP, there's no way for a
> tracer to do a very non-invasive SEIZE, say, a GDB mode that
> only cares to let the tracer run free to catch SIGSEGVs
> in some child, while later on during the run, the user remembers
> to set a breakpoint.  At that point the tracer needs to catch
> exec events, so it'd enable TRACE_O_EVENTEXEC.  Getting rid of
> the SIGTRAP gets rid of the spurious stops when TRACE_O_EVENTEXEC
> is not enabled.

This part I don't understand.

(btw, PTRACE_O_TRACEEXEC, not TRACE_O_EVENTEXEC).

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ