linux-kernel - Re: [PATCH 00/23] tracehook

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: <20080718080751.GG6875@elte.hu>
Date:	Fri, 18 Jul 2008 10:07:51 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Roland McGrath <roland@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/23] tracehook

* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Thu, 17 Jul 2008 00:25:41 -0700 (PDT) Roland McGrath <roland@...hat.com> wrote:
> 
> > This patch series introduces the "tracehook" interface layer of 
> > inlines in <linux/tracehook.h>.
> 
> Looks sane to me from a quick scan.

same here.

Reviewed-by: Ingo Molnar <mingo@...e.hu>

> A ~200 byte increase in i386 allnoconfig .text is liveable with.  But 
> nothing defines CONFIG_HAVE_ARCH_TRACEHOOK yet.  What effect will that 
> have?

this is the second subtle step towards utrace and 
next-gen-instrumentation. (regset was the first, by far most risky step)

> I don't like the name!  We have ftrace and we have static tracepoints 
> and we have dynamic tracepoints and we have linux trace toolkit and 
> whatever is in kernel/trace/trace.c etc, etc.  Now this work comes 
> along with _userspace_ tracing capabilities and it goes and calls it, 
> of all things, "trace"!

> Apart from that, I think the other big issue with this patchset is 
> that it doesn't do anything yet.  It's effectively a blank cheque.  
> There's not a lot of point in merging all this work unless we also 
> merge something which uses it (is this correct?).  And afacit the 
> thing which will use it is utrace and utrace hasn't been sighted for a 
> year or more and it has met objections.
> 
> If we merge this and then utrace crashes on a rocky shore then there 
> was no (or little) point in having merged this.
> 
> Or am I wrong about that?  Does it have sufficient standalone value to 
> justify a standalone merge (yet alone to justify such a late merge)?

It has enough standalone value to me - it generally cleans up all things 
"abstract kernel events", collects them into a single entity and lets 
tracers interact with the kernel (not just passively observe its 
events). So it's good for next-gen debuggers too, etc.

And task_current_syscall() avoids us hundreds of crappy hooks in every 
syscall handler and gives us in-kernel strace in essence. (it's not just 
useful to sample blocked threads - it could also be used by ftrace&co to 
sample the currently executing task) That alone makes it worth it IMO 
;-)

also in places it cleans up current special-case-for-ptrace code and 
makes it shorter - like in kernel/exit.c. Well thought out scheme and 
structure - as we've come to expect from Roland.

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