linux-kernel - Re: [PATCH] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

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: <10785.1175247540@redhat.com>
Date:	Fri, 30 Mar 2007 10:39:00 +0100
From:	David Howells <dhowells@...hat.com>
To:	bryan.wu@...log.com
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag 

Wu, Bryan <bryan.wu@...log.com> wrote:

> It takes lots of time in malloc()->mmap()->do_mmap_private()->memset(). When
> malloc a big area, memset() the area to zero makes the performance very bad.

Ummm...

How do you then cope with attempting to run that same application under
MMU-mode Linux?  Won't MMU mmap() give EINVAL?  If so, then that'd be grounds
for NAK'ing this patch in the form given.

My theory is that NOMMU binaries should run just as well under an MMU-mode
kernel as under a NOMMU kernel.

What you're asking for is also a security risk - though obviously on NOMMU-mode
one that's fairly irrelevant.  It might even make a lot of sense there to move
the clearance into uClibc where possible rather than doing it in the kernel.

On MMU-mode kernels, the option should just be ignored.

I'd also recommend you stick a 'D' on the end of 'MAP_UNINITIALIZE' or may be
call it MAP_UNCLEARED'.  But that's a minor point, but you're not telling
mmap() to go and uninitialise the memory...

Lastly, why do you actually need VM_UNINITIALIZE at all?  The flag is only used
in a place where MAP_UNINITIALIZE is still available (okay, you'll have to hand
it down as an extra argument).  That looks like a waste of a VM_xxx flag, and
we don't have that many to spare.

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/