linux-kernel - Re: perf: record segfaults for cycles event when collecting data on a VM

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: <20120209133446.GD8830@elte.hu>
Date:	Thu, 9 Feb 2012 14:34:47 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Joerg Roedel <joerg.roedel@....com>
Cc:	David Ahern <dsahern@...il.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Jason Wang <jasowang@...hat.com>
Subject: Re: perf: record segfaults for cycles event when collecting data on
 a VM


* Joerg Roedel <joerg.roedel@....com> wrote:

> On Thu, Feb 09, 2012 at 08:30:24AM +0100, Ingo Molnar wrote:
> > 
> > * Joerg Roedel <joerg.roedel@....com> wrote:
> > 
> > > > which makes sense. It forces 
> > > > perf_session__find_machine_for_cpumode() to return the host 
> > > > machine always.
> > > 
> > > Great, thanks. I will send two patches tomorrow to fix Jason's 
> > > problem and change the default for perf_guest.
> > 
> > Well, if the crash is fixed then the the default can stay, 
> > right?
> 
> David's crash is fixed by changing the default back to its 
> original value :)

Then that's the wrong fix really.

> > Generally we should treat all input data in a perf.data or even 
> > the bits we get in the ring-buffer as external data that has to 
> > be checked carefully, with no assumptions made about data.
> 
> Well, there are two options:
> 
> 	1) Make sure machine == NULL does not happen. Changing the
> 	   default of perf_guest back to false does exactly this for
> 	   David's problem.

So what if it's turned on by the user? Do we still crash 
occasionally?

> 	2) Make sure that a machine == NULL pointer is never
> 	   dereferenced
> 
> I was going to fix it with option 1. Do you suggest option 2 is better?

Looks like the better fix. You said:

> Bottom line is that the perf-tool may receive samples tagged 
> as GUEST_KERNEL even when guest-sampling is disabled (probably 
> a race-condition). The perf-tool can not find a valid machine 
> pointer for such a sample and passes NULL down to the other 
> functions. And some functions don't seem to handle this.

tooling should never be surprised by getting some unexpected 
sample via the perf.data or the ring-buffer - regardless of 
whether that functionality is default enabled or manually 
enabled.

Thanks,

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