linux-kernel - Re: [GIT PULL] tracing: make signal tracepoints more useful

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: <20120117124023.GA13969@elte.hu>
Date:	Tue, 17 Jan 2012 13:40:23 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Seiji Aguchi <saguchi@...hat.com>,
	linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [GIT PULL] tracing: make signal tracepoints more useful

* Steven Rostedt <rostedt@...dmis.org> wrote:

> On Tue, 2012-01-17 at 11:02 +0100, Ingo Molnar wrote:
> 
> > That is not true *AT ALL* in such an unqualified manner. Steve, 
> > stop being stupid.
> > 
> > The kernel syscall ABI may indeed sometimes expand *INPUT* 
> > structures (if via some mechanism it's possible to make sure 
> > that old ABI uses don't cause the kernel to read undefined 
> > data), but the trace events are *OUTPUT* structures.
> 
> The difference between syscalls and tracepoints is that a 
> tracepoint always reports the size of the structure that was 
> read, where a syscall does not. So I do consider this similar 
> to reading the /proc/stat file as the user can see how much 
> was read. The backwards compatibility should be easy to write. 
> Old tools should not break, because it wont be reading the new 
> fields, and new tools can determine which tracepoint is there 
> because it is trivial to see which version of the tracepoint 
> is there because of the size read.

Any tool that requests the signal trace event, and copies the 
full (and now larger) record it got in the ring-buffer, without 
expanding the target record's size accordingly will *BREAK*. 

I do not claim that tools will break in practice - i'm raising 
the *possibility* out of caution and i'm frustrated that you 
*STILL* don't understand how ABIs are maintained in Linux. 

You arguing about defined semantics is *MEANINGLESS*. What 
matters is what the apps do in practice. If the apps we know 
about do it robustly and adapt (or don't care) about the 
expansion, and if no-one reports a regression in tools we don't 
know about, then it's probably fine.

But your argument that expansion is somehow part of the ABI is 
patently false and misses the point. Seeing your arguments make 
me *very* nervous about applying any ABI affecting patch from 
you.

Thanks,

	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/