linux-kernel - Re: [PATCH RFC 2/3] x86: Add Intel PT logger

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: <87a8ufl493.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Wed, 29 Jul 2015 12:09:12 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Takao Indoh <indou.takao@...fujitsu.com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, a.p.zijlstra@...llo.nl,
	acme@...nel.org, vgoyal@...hat.com
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH RFC 2/3] x86: Add Intel PT logger

Takao Indoh <indou.takao@...fujitsu.com> writes:

> On 2015/07/29 15:08, Alexander Shishkin wrote:
>> Instead, we should be able to do use the existing perf functionality to
>> enable the system-wide tracing, so that it goes through the
>
> "existing driver" means PMU driver (perf_event_intel_pt.c)?

Yes.

> The feature of these patches is a sort of flight recorder. Once it
> starts, never stop, not export anything to user, it just captures data
> with minimum overhead in preparation for kernel panic. This usage is
> different from perf and therefore I'm not sure whether this feature can
> be implemented using perf infrastructure.

Why not? There is an established infrastructure for in-kernel perf
events already, take a look at the nmi watchdog, for example.

>> driver. Another thing to remember is that you'd also need some of the
>> sideband data (vm mappings, context switches) to be able to properly
>> decode the trace, which also can come from perf. And it'd also be much
>> less code. The only missing piece is the code that would allocate the
>> ring buffer for such events.
>
> The sideband data is needed if we want to reconstruct user program flow,
> but is it needed to reconstruct kernel panic path?

You are not really interested in the panic path as much as events
leading up to the panic and those usually have context, which is much
easier to reconstruct with sideband info. Some of it you can reconstruct
by walking kernel's data structures, but that is not reliable after the
panic.

Regards,
--
Alex
--
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/