linux-kernel - Re: [RFC] Proposal for ptrace improvements

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] [day] [month] [year] [list]

Message-ID: <y0mtyf6wm0y.fsf@fche.csb>
Date:	Sun, 13 Mar 2011 21:03:57 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	Tejun Heo <tj@...nel.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, jan.kratochvil@...hat.com,
	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements

Hi -

tj wrote:

> [...]
>> I've said before more than once what I think are the important
>> principles about compatibility that ought to be maintained [...]
> The biggest changes the current ptrace users are gonna see are
> probably the ones from P1 and those are really corner cases - /proc
> state, behavior change visible only to other thread in a multithreaded
> debugger [...]
> Also, ptrace is inherently a very heavy mechanism.  [...]
> If someone is looking for completely transparent light weight
> monitoring [look elsewhere...]
> I skipped a lot of parts but in general I think that you're trying
> to do too much with ptrace.  ptrace has its place which is called
> debugging.  [...]

Take care not to define your problems away by something close to a
false dichotomy: intrusive ptrace vs. transparent tracing.  One needs
transparent enough debugging too, so that the presence of the debugger
does not subvert the occurrence of complex or transient phenomena.
This hazard is especially acute for multithreaded programs.  While
ptrace is known to be an imperfect substrate for multithreaded
debugging, it would be nice not to make it any worse.

Note that I'm not claiming that your current proposals necessarily
would do so, but the argument for treating ptrace as machinery
appropriate only for "heavy-weight diddling" could lead that way.

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