linux-kernel - Re: [RFC, PATCH 0/2] utrace/ptrace: simplify/cleanup ptrace attach

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: <20090506090512.GB24692@elte.hu>
Date:	Wed, 6 May 2009 11:05:12 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>, jdike@...toit.com,
	utrace-devel@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC, PATCH 0/2] utrace/ptrace: simplify/cleanup ptrace attach


* Christoph Hellwig <hch@...radead.org> wrote:

> On Wed, May 06, 2009 at 10:12:25AM +0200, Ingo Molnar wrote:
> > Yes. But realize the fundamental reason for that: _without_ 
> > ptrace-over-utrace the utrace core code is a big chunk of dead code 
> > only used on the fringes. I see and agree with all the future uses 
> > of utrace, but it's easy to be problem-free if a facility is not 
> > used by anything significant.
> 
> The ptrace cleanups might be required for utrace, but they by
> themselves don't make utrace any more useful without another
> user.
> 
> > So a clean ptrace-over-utrace plugin is absolutely needed for utrace 
> > to go upstream in v2.6.31. The ftrace plugin alone does not justify 
> > it. The real prize here is a (much!) cleaner ptrace code. Once 
> > ptrace is driven via utrace and it works, its value (and trust 
> > level) will skyrocket.
> 
> There are two blockers for utrace:
> 
>  - first all architectures need to be converted to the ptrace world
>    order with regsets, tracehooks and so on.  I hope we are on track
>    to get this done now after I've pinged all arch maintainers.

It might be more effective if you also wrote patches and if you 
would shop for maintainer Acks, instead of just "pinging" people? 
;-) We've already got enough would-be-managers on lkml really.

>  - we actually need a useful user of the utrace abstraction.  And just
>    converting ptrace to make it slightly more complicated by using
>    another abstraction just isn't it.  One useful bit that is in the
>    queue is a in-kernel gdbstub for user process which would allow
>    to get out of the ptrace and re-parenting mess for basic use
>    cases.  But a really convincing user would be even better.
> 
> I don't think 2.6.31 is a very realistic target.  While a lot of 
> arch maintainers are working on their ptrace code 2.6.31 is just a 
> too short deadline, and I'm also not sure we'll have the ptrace 
> code in shape by then.  2.6.32 is much more realistic.

Really, the above isnt a blocker list, it's your personal wish-list 
for the future. Cleaning up ptrace itself is already an upstream 
advantage worth having - for years ptrace was barely maintained. It 
interfaces to enough critical projects (gdb, strace, UML, etc.) to 
be a realiable (and testable) basis for utrace.

The new features you are suggesting look potentially interesting, 
but they have zero usage right now and they will take time to 
develop. So they should be decoupled, otherwise we will just have a 
huge and problematic change-the-world merge down the line, instead 
of a more manageable gradual approach.

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