Re: kern/50469: PaX ASLR breaks netbsd32 emulation

[Pierre Pronchery <khorben%defora.org@localhost>]

The following reply was made to PR kern/50469; it has been noted by GNATS.

From: Pierre Pronchery <khorben%defora.org@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, Christos Zoulas <christos%zoulas.com@localhost>
Subject: Re: kern/50469: PaX ASLR breaks netbsd32 emulation
Date: Sun, 20 Mar 2016 14:48:19 +0100

 On 03/20/16 13:08, Martin Husemann wrote:
 > On Sun, Mar 20, 2016 at 01:13:10AM +0100, Pierre Pronchery wrote:
 >> I finally managed to do enough of this to fix 32-bits emulation.
 > 
 > I still think this is wrong. The code should not hardcode UINT_MAX
 > as upper limit and fail-and-recover sounds like a bogus aproach
 > for this anyway.
 
 This has nothing to do with ASLR but with 32-bits emulation. The check
 with UINT_MAX is performed regardless of the presence of ASLR. The same
 check can also be found in emul_sunos32 and emul_svr4_32 (I have a
 separate patch for both, in the same branch).
 
 The recovery code is independent from the actual fix (as can be seen
 from my commit messages). I wrote and added this part here because:
 - there were comments mentioning it should be done;
 - this code path was hit in the case of ASLR because the offset it
   applies did not fit in the address range.
 
 Ironically in the case of ASLR it was not possible to recover, since
 sys_munmap() checks if the address to unmap is in range; thus leaking an
 entire memory area in the process...
 
 > Why not create proper VA limits for aslr and set them up MD and emulation
 > specific?
 
 ASLR has no specific VA limit that I can see.
 
 -- 
 khorben