linux-kernel - Re: [discuss] [PATCH] Inconsistent mmap()/mremap() flags

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, 2 Oct 2007 15:16:28 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Andi Kleen <ak@...e.de>
cc:	discuss@...-64.org, Thayne Harbaugh <thayne@...net>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [discuss] [PATCH] Inconsistent mmap()/mremap() flags

On Tue, 2 Oct 2007, Andi Kleen wrote:
> 
> > First call mmap with a low hint address, the new size you'll be wanting
> > from the mremap, PROT_NONE, MAP_ANONYMOUS, -1, 0.  Then call mremap with
> > old address, old size, new size, MREMAP_MAYMOVE|MREMAP_FIXED, and new
> > address as returned by the preparatory mmap.
> 
> That's racy unfortunately in a multithreaded process. They would need to loop.

Perhaps.  Though I don't see what your loop would be doing;
and the mapping established by the first thread would only
be vulnerable to another thread if that were really set on
interfering (an un-FIXED mmap by another thread will keep
away from the area assigned to the first).

Certainly a two-stage procedure has to be weaker than one stage,
but it is just how MAP_FIXED is normally used (isn't it?): first
stake out an arena for all that's needed without MAP_FIXED, then
fit into it the actual mappings required using MAP_FIXED.  Blind
use of MAP_FIXED is always in danger of unmapping something vital.

But whether the two-stage procedure is good enough for Thayne's
purpose, he'll have to judge for himself.

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/