linux-kernel - Re: [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]

Message-Id: <200710011313.30171.andi@firstfloor.org>
Date:	Mon, 1 Oct 2007 13:13:30 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	thayne@...net
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	discuss@...-64.org
Subject: Re: [PATCH] Inconsistent mmap()/mremap() flags


> @@ -388,6 +392,9 @@
>  			if (vma->vm_flags & VM_MAYSHARE)
>  				map_flags |= MAP_SHARED;
>  
> +			if (flags & MAP_32BIT)
> +				map_flags |= MAP_32BIT;
> +
>  			new_addr = get_unmapped_area(vma->vm_file, 0, new_len,
>  						vma->vm_pgoff, map_flags);
>  			ret = new_addr;

That's not enough -- you would also need to fail the mremap when the result
is > 2GB (MAP_32BIT is actually a MAP_31BIT) 

But that would be ugly to implement without a new architecture wrapper
or better changing arch_get_unmapped_area()

It might be better to just not bother. MAP_32BIT is a kind of hack anyways
that at least for mmap can be easily emulated in user space anyways.
Given for mremap() it is not that easy because there is no "hint" argument
without MREMAP_FIXED; but unless someone really needs it i would prefer
to not propagate the hack. If it's really needed it's probably better
to implement a start search hint for mremap()

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