http://bugs.winehq.org/show_bug.cgi?id=58480
Bug ID: 58480 Summary: winebuild ASLR breaks older DLLs Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: tres.finocchiaro@gmail.com Distribution: ---
The following commit (to the best of my understanding) introduces build flags to the PE sections of a wineg++ produced '.so.exe' file that force ASLR/DYNAMICBASE onto executables that it creates.
https://github.com/wine-mirror/wine/commit/518e394794160818ffe6826c874ff2f55...
As identified downstream with mingw and msvc, some scenarios exist where this ASLR/DYNAMICBASE must be disabled for the highest compatibility with 3rd-party DLLs, specifically 3rd-party VST instrument and effect plugins as they're loaded through DAWs using a Linux-wine-bridge. (Linux can be read ambiguously here, the issue would impact Unixes too)
The downstream bug report encompases Windows and Wine instances of the LMMS application, however a solution exists on Windows for both the MSVC compiler as well as the mingw compiler (via relevant dynamicbase flags).
MSVC: https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase
mingw: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default
Applying a similar flag to wineg++/winegcc/winebuild has proven difficult without forking the winebuild executable. The stop-gap patch that LMMS has developed is provided here as a reference https://github.com/Fastigium/winebuild/commit/7f9e27e44cfb8eba79f3850f46e12f... however this patch requires us to add winebuild as a build-time dependency to our build system. This is OK for a stop-gap, but as a long-term solution, I would like advice from the winehq team on how to support legacy DLLs (such as pre-Vist VST plugins) through a wine-bridge as a long-term solution.
http://bugs.winehq.org/show_bug.cgi?id=58480
Tres Finocchiaro tres.finocchiaro@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression, win64 URL| |https://github.com/LMMS/lmm | |s/issues/7830
http://bugs.winehq.org/show_bug.cgi?id=58480
--- Comment #1 from Tres Finocchiaro tres.finocchiaro@gmail.com --- Mailing list convo that preceded/influenced this report: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/threa...
http://bugs.winehq.org/show_bug.cgi?id=58480
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- Please explain how to reproduce the error, ideally with a download.
http://bugs.winehq.org/show_bug.cgi?id=58480
--- Comment #3 from Tres Finocchiaro tres.finocchiaro@gmail.com --- Steps to reproduce:
* Download LMMS x86_64 nightly version (this link will eventually expire, any "nightly appimage from our downloads page will do until the patch is merged) https://lmms.io/download/artifact/3481767587
* Download and extract Synth1 VST Plugin here (extract to Downloads folder): https://daichilab.sakura.ne.jp/softsynth/Synth1V113beta3.zip
* Start LMMS by double-clicking on the .AppImage file
* On the left-hand side browse to "My Home", "Downloads", "Synth1"
* Drag "Synth1 VST64.dll" into an empty area of the Song-Editor
* Wait for the synth to load
* Once loaded, click the track label in the Song-Editor for Synth1 to open the Instrument window.
* Play a note through Synth1 by clicking a note on the piano at the bottom of the Instrument window.
* Play a second note, Synth1 will crash.
NOTE: Baseline testing a "good" result is a bit harder due to unrelated dependency changes in wine over the years, however we can provide a "working build" from older wineg++ versions by temporarily switching our CI to before the offending patch.
http://bugs.winehq.org/show_bug.cgi?id=58480
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=58480
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #4 from Bernhard Übelacker bernhardu@mailbox.org --- With lmms-1.3.0-alpha.1.862+4c3f819-linux-x86_64.AppImage I am able to receive a SIGSEGV at this instruction inside "Synth1 VST64.dll":
=> 0x6ffffc5e1a25 <s1vst!main+224789>: movss %xmm3,(%r9) (gdb) print/x $r9 $1 = 0xfeb8e9b0 (gdb) x/1xg $r9 0xfeb8e9b0: Cannot access memory at address 0xfeb8e9b0
With $r9 being 0xfeb8e9b0, seems no valid address because `cat /proc/$(pidof RemoteVstPlugin64.exe.so)/maps` shows no mapping at this address.
This is followed by a recursive SIGSEGV in RtlVirtualUnwind2. But I see this also with a build having 518e394794 reverted.
I tried also the windows nightly, to stay completely within wine boundaries, and this shows the same SIGSEGV. lmms-1.3.0-alpha.1.862+4c3f819-mingw-win64.exe. https://lmms.io/download/artifact/3481792904
=> 0x6fffe9451a25 <s1vst!main+224789>: movss %xmm3,(%r9) (gdb) print/x $r9 $1 = 0xfe9be1a0 (gdb) x/1xg $r9 0xfe9be1a0: Cannot access memory at address 0xfe9be1a0
`cat /proc/$(pidof 'C:\Program Files\LMMS\plugins\RemoteVstPlugin64.exe')/maps` shows again no mapping at this address.
This happens here also with 518e394794 reverted.
Running without attached gdb makes winedbg attach which shows a lengthy backtrace, but all in `synth1 vst64.dll` or remotevstplugin64.exe, without any debug information.
http://bugs.winehq.org/show_bug.cgi?id=58480
--- Comment #5 from Tres Finocchiaro tres.finocchiaro@gmail.com --- @Bernhard,
`cat /proc/$(pidof 'C:\Program Files\LMMS\plugins\RemoteVstPlugin64.exe')/maps`
shows again no mapping at this address.
This happens here also with 518e394794 reverted.
This is because 518e394794 is a winebuild change!
Testing a baseline is difficult (it requires compiling LMMS against an older version of winebuild). This is a winegcc/wineg++/winebuild **compiler** regression. Reverting wine to an older version CANNOT restore the old behavior. I've explained this in my testing steps. Requoting:
NOTE: Baseline testing a "good" result is a bit harder due to unrelated dependency changes in wine over the years, however we can provide a "working build" from older wineg++ versions by temporarily switching our CI to before the offending patch.
I understand that this bug is filed against "Wine" but this is NOT a runtime regression. I chose "Wine" because I could not find a category suitable for winegcc/wineg++/winebuild.
I hope this information is helpful.
http://bugs.winehq.org/show_bug.cgi?id=58480
--- Comment #6 from Tres Finocchiaro tres.finocchiaro@gmail.com ---
I tried also the windows nightly, to stay completely within wine boundaries,
and this shows the same SIGSEGV.
The Windows nightly has this bug too! If you want to baseline test against Windows, you will need a build with DYNAMICBASE disabled in mingw or MSVC. They're available here: https://lmms.io/download/pull-request/7976#windows
(These download links will eventually expire)
-
WineHQ Bugzilla