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: <6d6a94c50703300334w6b4787f3p144715de5166d7bc@mail.gmail.com>
Date:	Fri, 30 Mar 2007 18:34:15 +0800
From:	"Aubrey Li" <aubreylee@...il.com>
To:	"David Howells" <dhowells@...hat.com>, vapier.adi@...il.com,
	jie.zhang@...log.com
Cc:	bryan.wu@...log.com, "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

On 3/30/07, David Howells <dhowells@...hat.com> wrote:
> 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.
>

Well, I don't understand why we have to clear the allocation memory.
I suggest we just remove the memset(addr, 0, len) operation at all.
Read the malloc manual, you'll get
--------
malloc() allocates size bytes and returns a pointer to the allocated memory.
****The memory is not cleared.****
--------
So, if not clearing the memory causes one application hang/crash,
that's the bug of that application and it need to be fixed.

The patch in my option is:
------------------------------------
diff --git a/mm/nommu.c b/mm/nommu.c
index cbbc137..fe2b6d4 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -759,10 +759,6 @@ static int do_mmap_private(struct vm_are
                /* clear the last little bit */
                if (ret < len)
                        memset(base + ret, 0, len - ret);
-
-       } else {
-               /* if it's an anonymous mapping, then just clear it */
-               memset(base, 0, len);
        }

        return 0;
----------------------------------------

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