linux-kernel - Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

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: <4B5FFADB.5090209@redhat.com>
Date:	Wed, 27 Jan 2010 10:35:39 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Jim Keniston <jkenisto@...ibm.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	ananth@...ibm.com, Arnaldo Carvalho de Melo <acme@...radead.org>,
	utrace-devel <utrace-devel@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Maneesh Soni <maneesh@...ibm.com>,
	Mark Wielaard <mjw@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

On 01/27/2010 10:24 AM, Ingo Molnar wrote:
>
>
>>> Not to mention that that process could wreck the trace data rendering it
>>> utterly unreliable.
>>>        
>> It could, but it also might not.  Are we going to deny high performance
>> tracing to users just because it doesn't work in all cases?
>>      
> Tracing and monitoring is foremost about being able to trust the instrument,
> then about performance and usability. That's one of the big things about
> ftrace and perf.
>
> By proposing 'user space tracing' you are missing two big aspects:
>
>   - That self-contained, kernel-driven tracing can be replicated in user-space.
>     It cannot. Sharing and global state is much harder to maintain reliably,
>     but the bigger problem is that user-space can stomp on its own tracing
>     state and can make it unreliable. Tracing is often used to figure out bugs,
>     and tracers will be trusted less if they can stomp on themselves.
>
>   - That somehow it's much faster and that this edge matters. It isnt and it
>     doesnt matter. The few places that need very very fast tracing wont use any
>     of these facilities - it will use something specialized.
>
> So you are creating a solution for special cases that dont need it, and you
> are also ignoring prime qualities of a good tracing framework.
>    

I see it exactly the opposite.  Only a very small minority of cases will 
have such severe memory corruption that tracing will fall apart because 
of random writes to memory; especially on 64-bit where the address space 
is sparse.  On the other hand, knowing that the cost is a few dozen 
cycles rather than a thousand or so means that you can trace production 
servers running full loads without worrying about whether tracing will 
affect whatever it is you're trying to observe.

I'm not against slow reliable tracing, but we shouldn't ignore the need 
for speed.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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