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]

Date:	Wed, 6 May 2009 04:23:00 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
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

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