linux-kernel - Re: [PATCH 0/2] utrace

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, 27 Aug 2008 02:34:03 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] utrace

On Tue, Aug 26, 2008 at 03:01:02PM -0700, Roland McGrath wrote:
> utrace is a new kernel-side API for kernel modules, intended to make it
> tractable to work on novel ways to trace and debug user-mode tasks.

Finally! Familiar code! :^)

> A previous utrace prototype was in all Fedora kernels since Fedora Core 6.
> Some substantial implementation and API details in the current code are
> different from those past versions.

And some internal details still horrible and overdesigned just like at
the very beginning.

> Please look freshly at these patches.

Well, all comments on tracehook patches were ignored.

> This code cannot be enabled without CONFIG_HAVE_ARCH_TRACEHOOK and the arch
> details it indicates.  In Linus's tree as of v2.6.27-rc4, only powerpc and
> sparc64 have that support.  The x86 support is available by merging in the
> tip/x86/tracehook branch.  For working on other arch support, there are some
> more details at http://sourceware.org/systemtap/wiki/utrace/arch/HowTo and
> these are mentioned in the comments in arch/Kconfig too (in v2.6.27-rc4).
> 
> The first patch adds the utrace kernel API (if CONFIG_UTRACE=y is set).
> There is no change at all without the config option, and with it there is
> no effect on anything at all until a kernel module using the utrace API is
> loaded.  There is detailed documentation on the API in DocBook form.
> 
> The second patch adds the CONFIG_UTRACE_PTRACE option.

If config option for ptrace is fine, please name it CONFIG_PTRACE.
For one, there will be no second tracing infrastracture. For two, nobody
but one man on the planet really cares how ptrace(2) is implemented.

> When set, this makes ptrace use the utrace API as much as is necessary so
> that using both ptrace and utrace to debug the same threads at the same time
> won't become confused.  The ptrace changes are somewhat kludgey.  They're
> intended to be the simplest, non-regressing thing that suffices to enable
> hacking on new utrace modules while also doing normal ptrace-based debugging.
> The ptrace implementation can still use many more cleanups later on.

General comments:

On the good side is per-task struct operation. This is good and should
be required from any such tracing facility.

Linked list of attached tracers? I don't know.

One the bad side, where are those nice tracing modules? Where are they?

I've heard rumours utrace is needed for frysk and frysk people were
pretty damn silent on linux-kernel.

On the homepage there is module which frozes task right before coredump.
AFAICS, Al Viro mentioned that non-schedulable TASK_BROKEN should be
sufficient for this without wasting all that time that went into
ptrace(2) stabilization and fixing holes in it.

This all similar to systemtap/markers story. Big changes under promises
that now, now somebody will use our thing.

General reminder:
people who collected ptrace(2) exploits proggies, try them again.

Now to code.

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