linux-kernel - Re: [PATCH 2/3] utrace core

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: <20090321014909.6b654f55.akpm@linux-foundation.org>
Date:	Sat, 21 Mar 2009 01:49:09 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Roland McGrath <roland@...hat.com>
Cc:	utrace-devel@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] utrace core

On Fri, 20 Mar 2009 18:41:40 -0700 (PDT) Roland McGrath <roland@...hat.com> wrote:

> This adds the utrace facility, a new modular interface in the kernel for
> implementing user thread tracing and debugging.  This fits on top of the
> tracehook_* layer, so the new code is well-isolated.
> 
> The new interface is in <linux/utrace.h> and the DocBook utrace book
> describes it.  It allows for multiple separate tracing engines to work in
> parallel without interfering with each other.  Higher-level tracing
> facilities can be implemented as loadable kernel modules using this layer.
> 
> The new facility is made optional under CONFIG_UTRACE.
> When this is not enabled, no new code is added.
> It can only be enabled on machines that have all the
> prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK.
> 
> In this initial version, utrace and ptrace do not play together at all.
> If ptrace is attached to a thread, the attach calls in the utrace kernel
> API return -EBUSY.  If utrace is attached to a thread, the PTRACE_ATTACH
> or PTRACE_TRACEME request will return EBUSY to userland.  The old ptrace
> code is otherwise unchanged and nothing using ptrace should be affected
> by this patch as long as utrace is not used at the same time.  In the
> future we can clean up the ptrace implementation and rework it to use
> the utrace API.

I'd be interested in seeing a bit of discussion regarding the overall value
of utrace - it has been quite a while since it floated past.

I assume that redoing ptrace to be a client of utrace _will_ happen, and
that this is merely a cleanup exercise with no new user-visible features?

The "prototype utrace-ftrace interface" seems to be more a cool toy rather
than a serious new kernel feature (yes?)

If so, what are the new killer utrace clients which would justify all these
changes?



Also, is it still the case that RH are shipping utrace?  If so, for what
reasons and what benefits are users seeing from it?


And I recall that there were real problems wiring up the Feb 2007 version
of utrace to the ARM architecture.  Have those issues been resolved?  Are
any problems expected for any architectures?

Thanks.

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