Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 356737 - dev-lang/mono incompatible with aslr, pie and large address spaces
Summary: dev-lang/mono incompatible with aslr, pie and large address spaces
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-27 19:12 UTC by Anders Hellgren
Modified: 2020-06-26 08:12 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Failure with mono-2.10 (dev-lang:mono-2.10.1-r1:20110227-175817.log.gz,122.83 KB, application/octet-stream)
2011-02-27 20:42 UTC, Anders Hellgren
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Hellgren gentoo-dev 2011-02-27 19:12:17 UTC
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.
Comment 1 Pacho Ramos gentoo-dev 2011-02-27 20:03:38 UTC
What mono version are you using? Also attach full build.log
Comment 2 Anders Hellgren gentoo-dev 2011-02-27 20:42:46 UTC
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.
Comment 3 Pacho Ramos gentoo-dev 2011-03-01 17:39:31 UTC
Could you please report this problem (and a patch) for fixing this directly to upstream also? Thanks

-> bugzilla.novell.com
Comment 4 Magnus Granberg gentoo-dev 2011-03-06 01:31:40 UTC
Disabling randmmap on the bin fix this error to.
But this bug should be open to we get a real fix.
Comment 5 Pacho Ramos gentoo-dev 2011-03-12 12:03:01 UTC
(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 ?
Comment 6 Pacho Ramos gentoo-dev 2011-03-21 19:43:32 UTC
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.
Comment 7 PaX Team 2011-03-25 11:47:33 UTC
i'll take a look at this next week, maybe i screwed up MAP32 handling in PaX.
Comment 8 Alistair Bush (RETIRED) gentoo-dev 2011-08-18 07:24:40 UTC
(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.
Comment 9 PaX Team 2012-01-31 11:19:54 UTC
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.
Comment 10 Pacho Ramos gentoo-dev 2016-09-21 10:05:54 UTC
I have no idea about if this was improved in more recent versions like 4.4.1.0 or newer :/