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: <55B98290.4090705@jp.fujitsu.com>
Date:	Thu, 30 Jul 2015 10:49:04 +0900
From:	Takao Indoh <indou.takao@...fujitsu.com>
To:	<alexander.shishkin@...ux.intel.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

On 2015/07/29 18:09, Alexander Shishkin wrote:
> 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.

Ok, I'm reading the code around perf_event_create_kernel_counter. It
seems to work for my purpose, I'll try to update my patch with this.

Thanks,
Takao Indoh

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