linux-kernel - Re: linux-next: add utrace tree

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:	Fri, 22 Jan 2010 18:45:41 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>, Fr??d??ric@...hat.com,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Peter Zijlstra <peterz@...radead.org>,
	Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	linux-next@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	utrace-devel@...hat.com, Linus <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: linux-next: add utrace tree

On 01/21, Andrew Morton wrote:
>
> ptrace is a nasty, complex part of the kernel which has a long history
> of problems, but it's all been pretty quiet in there for the the past few
> years.

Well, yes, I'd say ptrace is "frozen". Nobody add new features/improvements,
only bugfixes.

> This leads one to expect that a rip-out-n-rewrite is a
> high-risk prospect.  So, quite reasonably, one looks for a good reason
> for taking such risk.

As it was already said, utrace was not created to just replace the current
ptrace.

However, speaking of ptrace, imho even ptrace-utrace is more flexible and
allows to improve this api easily.

Just for example, even attach and detach are not trivial to use from
user-space when it comes to multithread tracees. A one-liner patch for
ptrace-utrace can implement PTRACE_DETACH which doesn't need TASK_TRACED,
it is easy to avoid the initial SIGSTOP from attach (which doesn't always
work but strace/gdb relies on it).

Of course, I do not profess this is not posible with the current
implementation. But this will need more changes, and these changes will
touch the code outside of ptrace.c. And in fact I think that any
enhancements in this area will lead to rewrite of the current ptrace
code.

I must admit that personally I think the current ptrace api is unfixable,
we need the new one in the long term. It would be nice to just kill ptrace,
but this is not possible and that is why ptrace-utrace exists. And, if
nothing more, utrace allows to have both old and new ones without any
changes outside of ptrace/utrace code.

Oleg.

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