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]

Date:	Tue, 2 Oct 2007 07:15:26 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Thayne Harbaugh <thayne@...net>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, discuss@...-64.org
Subject: Re: [PATCH] Inconsistent mmap()/mremap() flags

On Mon, Oct 01, 2007 at 08:57:10PM -0600, Thayne Harbaugh wrote:
> Yeah, after I sent the email I realized that it was a bit more involved.
> As far as the 32/31 bit, it just depends on the perspective.  I can see
> that 32 bits are needed to represent all possible return values from
> mmap() - possible address and error value of -1.  From that perspective
> I think that MAP_32BIT is appropriate.

Your perspective seems quite narrow. Only using 2GB instead of 4GB 
is a major functional difference.

Negative error values are used in all system calls, so it would
hardly seem necessary to encode the use of the 32th bit for that
in the option name.

> > 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.
> 
> Care to give me some hints as to how that would be easily emulated in
> user space?  That might be a better solution for the case I want to
> solve.

For mmap you can emulate it by passing a low hint != 0 (e.g. getpagesize()) 
in address but without MAP_FIXED and checking if the result is not beyond
your range.

> 
> > 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()
> 
> It came up for user-mode Qemu for the case of emulating 32bit archs on
> x86_64 using mmap.  At the moment it calls mmap with MAP_32BIT and then

That would limit the 32bit architectures to 2GB; but their real limit
is 4GB. Losing half of the address space definitely would make users unhappy
(e.g. at least normal Linux kernels wouldn't run at all) 

The reason it's only 2GB is that the flag was added to support the small
code model of x86-64, which is limited to 2GB (31bit). Yes it's misnamed. 
But it's not used for the 32bit compat code.

> uses the returned address directly in the emulator.  Without MAP_32BIT
> there's the possibility of having an address that would be too large to
> pass to what a 32bit arch would expect.  Since the MAP_32BIT flag solves
> the problem for mmap()

It doesn't really for that case

> I was expecting something similar for mremap() -
> unfortunately the MAP_32BIT feature is consistent throughout.

I guess you mean inconsistent. 

Does qemu actually need mremap() ?  It would surprise me because
a lot of other OS don't implement it.

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