linux-kernel - RE: [tip:tracing/core] Revert "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:	Thu, 11 Jun 2009 10:08:55 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"oleg@...hat.com" <oleg@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: RE: [tip:tracing/core] Revert "x86, bts: reenable ptrace branch
 trace support"

On Thu, 2009-06-11 at 08:17 +0100, Metzger, Markus T wrote:
> >That would indeed keep the proposed ABI workable, what I'm still not
> >liking is that this buffer is in-kernel, but I guess that might be
> >something for other people to have an opinion on.
> 
> The alternative would be to give a user-allocated buffer to the tracing h/w.
> 
> We would need to take precautions to prevent the user from messing around
> with that buffer while the h/w is writing to it. Other code uses the kernel-
> allocated buffer plus copy_to_user() approach, as well.
> 
> Further, it would require the user to interpret the various tracing formats,
> whereas the existing interface provides an architecture-independent format.
> 
> 
> Does anybody have concerns on using an in-kernel buffer and providing a 
> copy_to_user() interface?

Ah, if you mmap() you can do without copy_to_user().

Either way, you have to make sure the buffer is mlocked() anyway, since
you're wanting to fill it from interrupt context.

The advantage (imo) from letting the user set it up is that you don't
need those separate allocation routines.

But yes, it would expose the data to the user, but one could keep it
opaque data, without requiring the user to be able to interpret it.

Of course a data format aligned with the interface capabilities would be
nicer ;-)

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