linux-kernel - Re: [tip:tracing/core] x86, bts: reenable ptrace branch trace support

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:	Wed, 10 Jun 2009 14:44:03 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	markus.t.metzger@...el.com, tglx@...utronix.de, oleg@...hat.com,
	mingo@...e.hu
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:tracing/core] x86, bts: reenable ptrace branch trace
 support

On Thu, 2009-05-07 at 09:25 +0000, tip-bot for Markus Metzger wrote:
> Commit-ID:  7e0bfad24d85de7cf2202a7b0ce51de11a077b21
> Gitweb:     http://git.kernel.org/tip/7e0bfad24d85de7cf2202a7b0ce51de11a077b21
> Author:     Markus Metzger <markus.t.metzger@...el.com>
> AuthorDate: Fri, 24 Apr 2009 09:44:48 +0200
> Committer:  Ingo Molnar <mingo@...e.hu>
> CommitDate: Fri, 24 Apr 2009 10:18:51 +0200
> 
> x86, bts: reenable ptrace branch trace support
> 
> The races found by Oleg Nesterov have been fixed.
> 
> Reenable branch trace support.
> 
> Signed-off-by: Markus Metzger <markus.t.metzger@...el.com>
> Acked-by: Oleg Nesterov <oleg@...hat.com>
> LKML-Reference: <20090424094448.A30216@...ona.ch.intel.com>
> Signed-off-by: Ingo Molnar <mingo@...e.hu>

OK, this whole BTS thing worries me because it seems to expose too much
of the Intel Debug Store thingy to the outside world.

The thing is, once we do PEBS from inside the kernel, we'll have to
share the debug store, and the way this thing sets it up isn't really
going to work.

So what I'd like to see is having this debug store removed from the
interface and abstracted away as cpu resource -- a single page when in
use should suffice I think.

If you want to expose a buffer to userspace, use the regular mmap()
interface and fill those pages from the DS interrupt handler.
--
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/