linux-kernel - Re: [PATCH v2] trace: Add x86 irq vector entry/exit tracepoints

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:	Thu, 7 Jul 2011 11:57:16 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Michael Rubin <mrubin@...gle.com>, x86@...nel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: [PATCH v2] trace: Add x86 irq vector entry/exit tracepoints

* H. Peter Anvin <hpa@...or.com> wrote:

> Yes, it was much more of a generic concern.  However, it is very 
> important that people have a correct idea about what the stability 
> of something like tracepoint is -- or we'll end up in a situation 
> where we can never change the kernel because anything is suddenly 
> "user space visible."

We've transitioned even ABI-assuming tracepoints in the past, so it's 
not a big issue in practice. The reason is that this is an atypical 
type of ABI: information is read-only exported, for observation 
purposes.

If the kernel changes in a fundamental way that removes a tracepoint 
altogether, then there's nothing left to observe - so apps don't 
break per se.

So i've yet to see a single example of the kernel 'never being able 
to change' due to a tracepoint. The worst we've seen in practice is 
the inability to change a specific tracepoint (not the surrounding 
kernel code - while preserving the information that is exposed) - so 
the worst effect was limited to tracing itself - never to the 
subsystem that it traces.

Note that even in that (single known) example we were able to resolve 
the problem (which was limited to the tracing subsystem) by adding 
new tracepoints and thus phasing out the old ones.

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/