linux-kernel - Re: [PATCH 2/2] Add new PTRACE_O_TRACESTOP option, make it control new ptrace behavior.

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: <20110906230645.GB16976@htj.dyndns.org>
Date:	Wed, 7 Sep 2011 08:06:45 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Add new PTRACE_O_TRACESTOP option, make it control
 new ptrace behavior.

Hello,

On Tue, Sep 06, 2011 at 10:08:18PM +0200, Oleg Nesterov wrote:
> On 09/05, Denys Vlasenko wrote:
> > PTRACE_SEIZE does not assume PTRACE_O_TRACESTOP, but with this patch
> > it allows any PTRACE_O_opts to be set at attach time
> 
> Well. This assumes that the only difference with PTRACE_SEIZE is the
> new stop/interrupt behaviour. I am not sure this is "safe" to assume.
> 
> Tejun, what do you think?

The biggest problem would be locking against the tracee.  Currently,
it's assumed that the behavior is determined at seize/attach time and
stay that way.  Tracee behaves differently to maintain compatibility
or show the new behavior.  If the state changes on the fly, we need to
change how tracee behaves.  Maybe we'll need some re-trap trickery or
can just get away with making tracee always behave in the new way and
somehow present it differently if !TRACESTOP.

That said, I can't see much point in this excercise.  Why does this
even matter?  This is almost purely cosmetic and any effect on the
usability of the API is so too.  The gained easiness of the API change
is in the realm of a few if statements.  There's nothing to be gained
by allowing flipping TRACESTOP.  Why would any program which is aware
of the new behavior turn it off and if not why would we want to
complicate things by supporting a feature which wouldn't be useful
risking higher chance of breakage (both from increased complexity and
lack of usage)?

ptrace is an ugly interface.  Some of that is inherent but probably
most of it is from how it was designed and has evolved over time.  As
far as I'm concerned, the goals are making it feature-complete and not
deviating too much from what's already there.

ptrace is painful to use with or without PTRACE_O_TRACESTOP.  IMHO, if
we want to address this issue, a better approach would be implementing
a wrapper library which hides the silliness of the kernel interface
and provides useable set of interface and information.

Thanks.

-- 
tejun
--
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/