linux-kernel - Re: ptrace API extensions for BTS

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: <200712071404.06594.ak@suse.de>
Date:	Fri, 7 Dec 2007 14:04:06 +0100
From:	Andi Kleen <ak@...e.de>
To:	"Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:	roland@...hat.com, markus.t.metzger@...il.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mingo@...e.hu, "Siddha, Suresh B" <suresh.b.siddha@...el.com>
Subject: Re: ptrace API extensions for BTS

On Friday 07 December 2007 13:01:28 Metzger, Markus T wrote:
> >From: Andi Kleen [mailto:ak@...e.de] 
> >Sent: Freitag, 7. Dezember 2007 12:18
> 
> >> I would like to settle the discussion and find an interface that
> >> everybody can agree to, so I can implement that interface and we can
> >> move forward with the patch.
> >
> >The most efficient interface would be zero copy with tracer 
> >user process
> >supplying memory that is pinned (get_user_pages()) subject to the
> >mlock rlimit. Then kernel telling the CPU to directly log into
> >that.
> 
> That would require users to understand all kinds of BTS formats
> and to detect the hardware they are running on in order to interpret
> the data.

That's true. I guess it could be abstracted in a library, but doing
it all in kernel is indeed nicer.

Ok in theory you could go fancy and put the library into the vDSO
which runs in ring 3. Then it would be tied to the kernel again.

> So far, there are two different formats. But one of them is wasting
> an entire word of memory per record. I could imagine that this would
> change some day.
> 
> Other architectures would likely use an entirely different format.
> Users who want to support several architectures would benefit from
> a common format for this from-to branch information.

I guess some other users would prefer higher performance, but yes
there are probably both types. I don't know what is more important.

> Is there some other metric that would allow me to order BTS 
> chunks for different threads?

With Out-of-order CPUs exact global metrics are pretty difficult.
At which point of the instruction execution would you measure? 

Anyways if RDTSC doesn't work the only global alternatives are much slower
(like southbridge timers) or very inaccurate (jiffies) 

I would just drop it since it'll likely always be somewhat misleading.

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