linux-kernel - Re: [PATCH 3/4] x86: Add trace point for MSR accesses

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: <20151201210334.4a1f9ea1@grimm.local.home>
Date:	Tue, 1 Dec 2015 21:03:34 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	x86@...nel.org, peterz@...radead.org, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 3/4] x86: Add trace point for MSR accesses

On Tue,  1 Dec 2015 17:00:59 -0800
Andi Kleen <andi@...stfloor.org> wrote:

> From: Andi Kleen <ak@...ux.intel.com>
> 
> For debugging low level code interacting with the CPU
> it is often useful to trace the MSR read/writes. This gives
> a concise summary of PMU and other operations.
> 
> perf has an ad-hoc way to do this using trace_printk,
> but it's somewhat limited (and also now spews ugly boot
> messages when enabled)
> 
> Instead define real trace points for all MSR accesses.
> 
> This adds three new trace points: read_msr and write_msr
> and rdpmc.
> 
> They also report if the access faulted (if *_safe is used)
> 
> This allows filtering and triggering on specific
> MSR values, which allows various more advanced
> debugging techniques.
> 
> All the values are well defined in the CPU documentation.
> 
> The trace can be post processed with
> Documentation/trace/postprocess/decode_msr.py
> to add symbolic MSR names to the trace.
> 
> I only added it to native MSR accesses in C, not paravirtualized
> or in entry*.S (which is not too interesting)
> 
> Originally the patch kit moved the MSRs out of line.
> This uses an alternative approach recommended by Steven Rostedt
> of only moving the trace calls out of line, but open coding the
> access to the jump label.
> 
> v2:
> Move MSR trace events to arch/x86/include/asm/msr-trace.h
> Signed-off-by: Andi Kleen <ak@...ux.intel.com>
>

For the general tracing part.

Acked-by: Steven Rostedt <rostedt@...dmis.org>

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