Summary: | dev-lang/mono incompatible with aslr, pie and large address spaces | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anders Hellgren <kallamej> |
Component: | Current packages | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | dotnet, gentoo.qxrin, jackdachef, pageexec |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Failure with mono-2.10 |
Description
Anders Hellgren
2011-02-27 19:12:17 UTC
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 :/ |