Compiling mono on a hardened host with a large amount of RAM gives the following error. V: mono_create_corlib_exception_0 * Assertion at mini-amd64.c:501, condition `amd64_is_imm32 (disp)' not met According to http://lists.ximian.com/pipermail/mono-list/2007-March/034497.html mono assumes in many places that executable code is reachable within +/- 2 GB. However, that assumption may not be met on aslr+pie systems with enough RAM. A fix is to add #define MONO_ARCH_NOMAP32BIT to mono/mini/mini-amd64.h.
What mono version are you using? Also attach full build.log
Created attachment 264097 [details] Failure with mono-2.10 The same problem exists with 2.8. Due to the nature of the problem it will happen at different times during the compilation.
Could you please report this problem (and a patch) for fixing this directly to upstream also? Thanks -> bugzilla.novell.com
Disabling randmmap on the bin fix this error to. But this bug should be open to we get a real fix.
(In reply to comment #4) > Disabling randmmap on the bin fix this error to. > But this bug should be open to we get a real fix. Can you please report this to upstream with suggested fix by Anders -> bugzilla.novell.com ?
As talked with upstream in #mono IRC channel: (20:16:41) pacho: regarding "#define MONO_ARCH_NOMAP32BIT" problem, should I open an upstream bug report? (20:19:34) vargaz: pacho1: disabling that is not a good fix. (20:24:01) pacho: vargaz: what would be a better fix? (20:24:40) vargaz: pacho1: doing a runtime check for that stuff which breaks mono. (20:25:31) vargaz: because MONO_ARCH_NOMAP32BIT means that the MAP_32BIT option to mmap does not work. (20:26:16) vargaz: which is not good, since mmap should either support that option, or return an error, not silently ignore it. (20:27:07) pacho: where would be the problem then? Maybe in hardened as mono compilation fails on such setups :-/ (20:27:52) vargaz: the problem is that mmap ignores the PROT_32BIT flag passed to it. (20:27:58) vargaz: which it shouldn't. (20:31:34) kumpera: vargaz: MAP_32BIT only works on amd64 (20:31:52) vargaz: its on amd64. (20:32:03) vargaz: some crazy security stuff breaks it. (20:34:09) pacho: maybe it's caused by hardened then :-| (20:38:36) vargaz: pacho1: someone needs to figure out what breaks it, then we can add a runtime detection for it, like by checking for it in /proc or something. (20:38:57) vargaz: in the meantime, you can include that change in the gentoo packages.
i'll take a look at this next week, maybe i screwed up MAP32 handling in PaX.
(In reply to comment #7) > i'll take a look at this next week, maybe i screwed up MAP32 handling in PaX. ping on this.
sorry that i didn't look at this earlier. my findings: 1. i can successfully emerge mono-2.10.8 with a modified ebuild where ASLR is enabled (and MPROTECT stays disabled) on amd64 with the normal toolchain (not hardened). 2. i checked my code and MAP_32BIT is honoured and handled properly, a simple test app confirmed it too. this makes me think that the problem is not with MAP_32BIT support per se, but rather some other assumption in mono regarding its use. in particular, from a cursory look it seems that this mapping kind is used for runtime generated code that i presume is expected to be able to call back to the main executable using a direct call, however that won't get far if the main executable itself is a PIE (that the hardened toolchain creates by default) as PaX may very well randomize it beyond the lower 2GB. the vanilla kernel can do the same these days, so i wonder whether people can reproduce this there too.
I have no idea about if this was improved in more recent versions like 4.4.1.0 or newer :/
