linux-kernel - Re: [PATCH] i386 add Intel PEBS and BTS cpufeature bits and detection

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, 16 Nov 2006 23:57:51 -0800
From:	Stephane Eranian <eranian@....hp.com>
To:	Andi Kleen <ak@...e.de>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	linux-kernel@...r.kernel.org, akpm@...l.org
Subject: Re: [PATCH] i386 add Intel PEBS and BTS cpufeature bits and detection

Jeremy,

On Fri, Nov 17, 2006 at 05:29:02AM +0100, Andi Kleen wrote:
> On Friday 17 November 2006 02:34, Jeremy Fitzhardinge wrote:
> > Stephane Eranian wrote:
> > > Here is a small patch that adds two cpufeature bits to represent
> > > Intel's Precise-Event-Based Sampling (PEBS) and Branch Trace Store
> > > (BTS) features. Those features can be found on Intel P4 and Core 2 
> > > processors among others and can be used by perfmon.
> > >   
> > 
> > I've been thinking it would be useful for kernel debugging if kernel
> > oops messages could use the branch history to show the last few jumps on
> > processors which support it.  It would help a lot with the "oh, an oops
> > with eip==esp==0" type crashes, which are otherwise pretty unhelpful.
> 
> I have had private patches for that myself, using the MSRs on AMD
> and Intel.
> 
> The problem is that you have to insert hooks early into the exception
> handlers to read the branch history MSRs, and that gets fairly ugly
> and a little slow and we can't really enable it by default.
> 
There are two ways of capturing branches on the Intel processors (I have not
looked at AMD): Last Branch Record (LBR) and Branch Trace Store (BTS). The former
stores from/to information into MSRs and is very small (4 branches). The later could
be as big as you want. On recent processors LBR and BTS can be constrained by priv level.
The issue is that they capture ALL taken branches, not just taken function call or return.

> But using BTS with a long in memory buffer would be fine. It would
> just be slower so it couldn't be enabled by default. But as a debugging
> feature it would be nice.
> 

Yes, I think it could be used for debugging, you'd need to reserve a few pages
and initialize a single MSR (32_DEBUGCTL).

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