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: <20131008095430.GQ3081@twins.programming.kicks-ass.net>
Date:	Tue, 8 Oct 2013 11:54:30 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Kees Cook <keescook@...omium.org>, Ingo Molnar <mingo@...nel.org>,
	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>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC] perf: mmap2 not covering VM_CLONE regions

On Tue, Oct 08, 2013 at 11:42:06AM +0200, Stephane Eranian wrote:
> On Tue, Oct 8, 2013 at 11:36 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Tue, Oct 08, 2013 at 09:15:30AM +0200, Stephane Eranian wrote:
> >> Yes, it is but I am trying to see whether or not we could unify that and
> >> use a single u64 number to uniquely identify each mapping.
> >
> > No you cannot; two unrelated executables which have distinct mm_ids can
> > easily mmap() the same shared file.
> 
> That seems to indicate the mm_ids is not attached to the right level of VM
> data structure. 

No that's not it.. shared mappings can create arbitrary couplings
between mm's, there's really nothing you can do about that.

This is really only about anonymous memory shared with CLONE_VM.

> But I am okay with keeping it that way and stashing the mm_id
> as a pseudo inode number for the case of non file-backed mappings. If we
> say maj=min=ino=gen=0 means no "info", then any other combinations can
> be used to identify identical mappings. We use actual min,maj, ino, gen
> for file backed, and maj=min=gen=0 + ino = mm_ids for the other cases.
> That should work, shouldn't it?

I'm not sure if min=maj=0 is a valid device, nor do I know if ino=0 is a
valid ino. But I suppose the name "//anon" should be a big enough clue
if both of those fail.
--
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/