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]

Message-ID: <Pine.LNX.4.64.0703051843030.10272@blonde.wat.veritas.com>
Date:	Mon, 5 Mar 2007 19:04:11 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	David Howells <dhowells@...hat.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 

On Sat, 3 Mar 2007, David Howells wrote:
> Hugh Dickins <hugh@...itas.com> wrote:
> 
> > > VMAs are a shared resource under NOMMU conditions.
> > 
> > That's a disturbing remark.
> 
> Why?  No-one complained when I first put up my rewrite patches three years ago.

Never mind whether anyone read your patches three years ago,
it's disturbing when one body of active developers perceives an object
as shared and another (largely disjoint) body of active developers
perceives it as private: great scope for disaster.

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

> 
> > I had thought Robin's suggestion very sensible; and throughout mm/
> > it has seemed pretty random whether we pass an "mm" argument down
> > in addition to "vma", or just take vma->vm_mm at whatever level needs.
> > 
> > You seem to be suggesting vma->vm_mm is dangerous when CONFIG_NOMMU,
> 
> vm_mm is never set to anything other than NULL if CONFIG_MMU=n and it doesn't
> seem to be a problem.  I don't think anything in the mm/ directory is left that
> looks at vm_mm once MMU support is disabled (in fact I've just checked, and I
> can compile with vm_mm #ifdef'd out)

That's reassuring, thanks.

> 
> > but we MMU people are scarily unaware of that.
> 
> If you're worryied that you can't compile anything for NOMMU, an FRV compiler
> is available, and a suitable NOMMU default config can be provided.
> Alternatively, you can pick ARM, M68K, ...
> 
> > Perhaps you need to put #ifndef CONFIG_NOMMU around vm_mm in struct
> > vm_area_struct?
> 
> 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.  I have the
impression, now reinforced by your defensive posture, that NOMMU is
a hack that squeamish outsiders had better not look too deeply into:
so long as it mostly works for those who need it to work,
we'd probably just be wasting your time anyway.

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