linux-kernel - Re: Move to unshared VMAs in NOMMU mode?

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: <11772.1174388792@redhat.com>
Date:	Tue, 20 Mar 2007 11:06:32 +0000
From:	David Howells <dhowells@...hat.com>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Hugh Dickins <hugh@...itas.com>, bryan.wu@...log.com,
	Robin Holt <holt@....com>,
	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>,
	Andrew Morton <akpm@...l.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	sugita <yumiko.sugita.yf@...achi.com>,
	Satoshi OSHIMA <soshima@...hat.com>, haoki@...hat.com,
	Robin Getz <rgetz@...ckfin.uclinux.org>
Subject: Re: Move to unshared VMAs in NOMMU mode? 

Eric W. Biederman <ebiederm@...ssion.com> wrote:

> As I understand your description for non-shared mappings the VMAs are
> per process.

Are you talking about the current state of play?  If so, not precisely.  In
the current scheme of things, *all* VMAs are kept in a global tree and are
globally available; it's just that any VMA that's not shareable will not be
shared, and so, in effect, is per-process.

In my suggested revamp, VMAs revert to being per-process objects only, and
sharing is effected by indirection.

> For shared mappings you share in some sense the page cache.

Currently, no - not unless the driver does something clever as ramfs does.
Sharing through the page cache is a nice idea, but it has some limitations,
mainly that non-sharing then operates differently.

> My gut feel says just keep a vma per process of the regions the
> process has and do the appropriate book keeping and all will be fine.

I'm sure it will be, but at the cost of consuming extra memory.  I'm not sure
that the amount of extra memory is, however, all that significant.  Now that I
think about it, I don't imagine that a lot of processes are going to be
running at once on a NOMMU system, and so the scope for sharing isn't all that
wide.

> For shm_nattach it looks like you simply are not calling the
> open/close methods on fork (because you have a shared pool of vmas).

There is no fork.

No, the problem is that sys_shmat() relies on do_mmap_pgoff() to call the VMA
open() method.  However, this assumes that a new VMA will be made per process.

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