linux-kernel - Re: [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory

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]

Date:	Tue, 06 Mar 2007 18:13:33 +0000
From:	David Howells <dhowells@...hat.com>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	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>,
	"Hideo AOKI@...hat" <haoki@...hat.com>
Subject: Re: [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory 

Hugh Dickins <hugh@...itas.com> wrote:

> > > Under precisely what NOMMU conditions?
> > 
> > CONFIG_MMU=n.
> 
> Believe it or not, I had just about grasped that subtlety.  I was
> rather expecting some helpful response along the lines of "we share
> all the vmas across a fork" or "whenever we go to allocate a vma, we
> look to see if there's already an isomorphic vma which we can share"
> or something like that.  But don't worry about it, the source is
> there for me to look at whenever.

Any VMAs that can be shared are, as a general rule.  It works this way because
shared MAP_PRIVATE read-only file data (such as a segment of an ELF
executable) is stored in a kmalloc()'d buffer attached to the VMA.  The
lifetime of this buffer is handled by the VMA, and the buffer is not part of
the pagecache.

Maybe it could be; that'd make the ramfs handling more consistent with normal
file handling.

Such things as mappable chardevs do get separate VMA's, but those don't own
the backing store.  That's configured through the BDI information in the
address_space.

> > I can if it makes you happier.  It's not strictly necessary, but it does
> > make the struct smaller which is good.
> 
> No, it doesn't really make me any happier: I expect that if I look any
> deeper, I'll just find plenty more to worry about there.

Good.  I was hoping someone else would review it.

> I have the impression, now reinforced by your defensive posture,

*shrug*  I was trying to keep the VMA as little changed as possible and add as
little extra to it as possible.

> that NOMMU is a hack that squeamish outsiders had better not look too deeply
> into:

Anyone that squeamish should avoid the full MMU VM like the plague then - it's
way way worse.  NOMMU is considerably simpler.  Yes, some liberties have to be
taken, but there's no avoiding that as there's no MMU available.  I've tried to
take as few as possible, and I've managed to make sure almost all the
functionality afforded by the MMU kernels is available.

> so long as it mostly works for those who need it to work, we'd probably just
> be wasting your time anyway.

*shrug* as you wish.

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/