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] [day] [month] [year] [list]

Message-ID: <20131009103932.GB3081@twins.programming.kicks-ass.net>
Date:	Wed, 9 Oct 2013 12:39:32 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Stephane Eranian <eranian@...gle.com>,
	David Ahern <dsahern@...il.com>,
	LKML <linux-kernel@...r.kernel.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

On Wed, Oct 09, 2013 at 11:59:06AM +0200, Ingo Molnar wrote:
> PeterZ didn't like exposing the physical RAM address, right?

More than not like; its useless and broken, see below.

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

No, all physical stuff is useless, a page can get moved about through
swap/ksm/thp/compaction/etc.

> The global MM ID thing looked rather ugly as well.

I'm still having the argument with Stephane -- although it fell off-list
-- on why this wouldn't work.

AFAICT the mm_id should work for CLONE_VM, as CLONE_VM inherits the
entire address space so all should be identical when mm_id match.

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

No, the inode stuff is required for shared pages, its the only way to
track them; and barring a filename (which we've so far used for this)
the dev:ino:gen thing is the only way to uniquely identify files -- it
even works where filenames don't, eg. filesystem namespaces and weird
things like shm that don't have stable filenames.
--
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/