Compiling mono on a hardened host with a large amount of RAM gives the following error.
* Assertion at mini-amd64.c:501, condition `amd64_is_imm32 (disp)' not met
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
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 126.96.36.199 or newer :/