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

Powered by blists - more mailing lists