linux-kernel - Re: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data'

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]

Message-Id: <201109101312.39256.pedro@codesourcery.com>
Date:	Sat, 10 Sep 2011 13:12:38 +0100
From:	Pedro Alves <pedro@...esourcery.com>
To:	Denys Vlasenko <vda.linux@...glemail.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 Saturday 10 September 2011 12:40:16, Denys Vlasenko wrote:
> On Saturday 10 September 2011 13:19, Pedro Alves wrote:
> > On Friday 09 September 2011 21:03:10, Denys Vlasenko wrote:
> > > 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.
> > 
> > But _without_ PTRACE_O_TRACEEXEC there is.  You've raised its
> > existence as justification for needing to be able to set
> > options directly on PTRACE_SEIZE.
> 
> It was an example. There may be other options with similar
> problem of "we want to enable new behavior ASAP, without
> waiting fro the first ptrace-stop".

As I said, there may be other examples, and I can see that
options-on-SEIZE is useful (it even makes the tracer less invasive,
as it doesn't force an interrup/stop for setting options), but as
I have been saying, that particular example IMO should be fixed
some other way.

(just-options-on-SEIZE scares me in terms of future expansion,
as it assumes only bitflags will ever be necessary.)

> > Point is, if we don't get rid 
> > of the SIGTRAP when PTRACE_O_TRACEEXEC is _not_ in effect, then
> > _everyone_ will always pass PTRACE_O_TRACEEXEC to SEIZE.
> 
> Yes, that's the nature of many options: they are fixing
> ptrace quirks, and therefore newer programs which know about
> these options will _always_ use them. 

I think it's better to work on a case by case basis, and not
claim all of them fix quirks.  In my mind, there are clearly different
sets of ptrace options.  PTRACE_O_TRACECLONE|FORK|VFORK|EXEC
forces _extra_ stops in the tracees that would not happen
if the tracee wasn't being traced in the first place (ignore the
magic exec SIGTRAP).

> For example, should we
> also unconditionally enable PTRACE_O_TRACESYSGOOD?

PTRACE_O_TRACESYSGOOD changes only the status reported by wait
on syscalls.  To get a syscall stop/SIGTRAP, you need to use
PTRACE_SYSCALL in the first place, and you can only do that
when the tracee is already ptrace stopped.  At that point, you
can just do PTRACE_O_TRACESYSGOOD yourself.  Nothing is seriously
lost if we don't enable it by default.  But it's fine with me
to enable it by default.

> I doubt about "significantly". fork and exec are heavy syscalls
> (they trash entire L1 data cache on today's CPUs), a ptrace stop
> on top of that is perhaps 10% slowdown _of the syscall_,
> about a few % slowdown overall.

There's the userland rountrip and context switches you get away
without.  With RT in the picture, it may be super important -- who
knows.

It's super easy to do it right.  IMO, let's just do it.

> > When a SIGSEGV happens, gdb can sync up about the process that crashed
> > from /proc.
> 
> It doesn't need to do even that - but probably will, gdb code is said
> to be quite complex. 

I happen to know gdb's code quite well.  ;-)

> and it will require a serious rewrite to get rid of that requirement.

Maybe, and it'd need a couple extra ptrace features (e.g., like being able
to make the tracer not see stops for signals it is not interested in.
Red Hat discussed some of those desirable ptrace features for making
gdb less invasive on the archer@ list a while ago.) but I'm
claiming it's better to leave the door open.

-- 
Pedro Alves
--
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/