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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ