[Bug 37034] Stars!: Crashes on startup

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Aug 5 17:57:51 CDT 2014


http://bugs.winehq.org/show_bug.cgi?id=37034

--- Comment #6 from planetbeing at gmail.com ---
(In reply to Ken Thomases from comment #5)
> (In reply to planetbeing from comment #2)
> > Found the real reason for this. The space was reserved by the WINE_DOS
> > segment. However, due to ASLR on Mac, that segment is always put into a
> > random location and does not start at 0x1000 as expected.
> 
> If those segments are not ending up in the correct place, then the solution
> is to fix that.  We may need to add "-no_pie" to the linker flags, perhaps
> instead of "-macosx_version_min 10.6".  See the setting of LDEXECFLAGS in
> configure.ac.

I think it's preferable not to disable security features if possible when the
application could be made to work without disabling them.

> 
> > It seems to me
> > that the correction solution is to reserve those segments correcting for the
> > ASLR slide. The previous patch helped but was unreliable. This new patch
> > seems to have solved the problem for good.
> 
> I don't understand how making reserve_area() reserve a different area then
> it was asked to helps anything.

The linker creates an executable with the WINE_DOS segment at 0x1000. On load
of the executable, dyld adds a slide to executable marked MH_PIE. The
__wine_dos symbol is relocated to 0x1000 + slide. When reserve_area is called,
it is called with 0x1000 + random slide. At least for WINE_DOS, asking for a
reservation at 0x1000 + random slide is not useful. There's no way to prevent
that while still referring to the area to be reserved through a symbol whose
location is defined by the compiler flag "-Wl,-segaddr" without subtracting the
slide first before calling reserve_area or else subtracting the slide in
reserve_area itself. It's still useful to define the linker segments to prevent
the rest of the code from ever being placed too low, but the actual reservation
must happen at non-slid addresses (at least for WINE_DOS, not sure if
WINE_SHAREDHEAP has specific address requirements).

It's possible to fix this with -Wl,-no_pie but that seems to me to be
needlessly removing a security mitigation.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list