Well, the official fix for mono is in, from the mono team.
Guess what ? Mono uses MAP_32BIT if it's available.
>From Linux's mmap manpage:
MAP_32BIT (since Linux 2.4.20, 2.6)
Put the mapping into the first 2 Gigabytes of the process
address space. This flag is only supported on x86-64, for
64-bit programs. It was added to allow thread stacks to be
allocated somewhere in the first 2GB of memory, so as to improve
context-switch performance on some early 64-bit processors.
Modern x86-64 processors no longer have this performance prob-
lem, so use of this flag is not required on those systems. The
MAP_32BIT flag is ignored when MAP_FIXED is set.
>From my point of view, it certainly looks like MAP_32BIT was only put there
to address one specific issue in the lifetime of 64 bit platforms, but that
some people got some nifty ideas about how to abuse it, and now it's probably
there to stay, since software would break without it...
And yeah, if MAP_32BIT is not available, you end up in a jungle of #ifdefs...
from what I see of the patch, it looks like the problem could affect
any 64 bits arch without MAP_32BIT.
We're probably just lucky to hit it first.
Let's stress out how MAP_32BIT is not such a good idea, since you constrain
the allocations into a much smaller address space, thus less random addresses,
more opportunities for buffer overflow to be exploited.
(but hey, we all know that buffer overflows don't ever happen under Linux,
which is why they don't need no shoddy strlcpy).
Differing opinions are welcome, but please, can you try to back it up with
facts ?
