Alex Rønne Petersen <[email protected]> wrote: > Hi, > > Running the attached C program results in this output: > > $ uname -mprsv > OpenBSD 7.8 GENERIC.MP#1 amd64 amd64 > $ cc bug.c > $ ./a.out > 0xffffffffffffffff (Cannot allocate memory) > > By my reading of POSIX, this seems bad;
Do me a favor and show the precise words where POSIX says this is "bad". You can use this file: https://pubs.opengroup.org/onlinepubs/9799919799/functions/mmap.html Quoting that page: > When MAP_FIXED is not set, the implementation uses addr in an > implementation-defined manner to arrive at pa. Our implementation-defined manner was chosen after recognizing that historically most developers used the hints unsafely, incorrectly, and were unintentionally undoing system-default address space randomization efforts. Hyrums law made them think this is a powerful method. > The pa so chosen shall be an area of the address space that the > implementation deems suitable for a mapping of len bytes to the > file. We consider a user recommendation without MAP_FIXED not suitable. Once all allocations are done via mmap(2), and the kernel does all process layout strongly random, and ld.so also gets into the game with almost no layout limitations, processes should not be placing objects at addresses they believe will work. An address that worked in a previous process is not going to work in a new process. The address space randomization found on other operating systems is not as maximally random as ours. > All implementations interpret an addr value of 0 as granting the > implementation complete freedom in selecting pa, subject to > constraints described below. A non-zero value of addr is taken to be a > suggestion of a process address near which the mapping should be > placed. When the implementation selects a value for pa, it never > places a mapping at address 0, nor does it replace any extant mapping. We intentionaly ignore the suggestion, because when we reviewed the body of code we found omre bad suggestions than good ones. By our definition, there is almost no way to make a good decision. The way you want this to work fits into that model of a bad idea. An address taken from a previous process runtime is a not a good hint for a new process runtime.
