linux-kernel - Re: [RFC] perf: mmap2 not covering 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: <20131009095906.GB17480@gmail.com>
Date:	Wed, 9 Oct 2013 11:59:06 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	David Ahern <dsahern@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jiri Olsa <jolsa@...hat.com>, Hugh Dickins <hughd@...gle.com>
Subject: Re: [RFC] perf: mmap2 not covering VM_CLONE regions


* Stephane Eranian <eranian@...gle.com> wrote:

> > Instead of a full revert we could just turn off the ABI portion 
> > minimally and not recognize it for now. Assuming a more complete 
> > solution is in the works for v3.13.
>
> That's a possibility. They are also pieces in the perf tool itself. We 
> could certainly make the attr->mmap2 bit disappear.
>
> I think it boils down to how can we uniquely identify virtual mapping to 
> the same physical data either via shmat(), files, VM_CLONE. We had all 
> covered but the last case with the ino approach. We don't have a 
> solution for VM_CLONE yet.

PeterZ didn't like exposing the physical RAM address, right?

Peter: could we expose the page frame number instead? (Maybe mix it with a 
random seed through the hash-mixer and expose that.) User-space will thus 
be able to discover whether two pages are shared or not, but not extract 
other information.

The global MM ID thing looked rather ugly as well.

That way we could drop the inode info as well? That feels a bit hacky too.

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/