[Bug 36664] New: Unable to run anything when with kernel version 3.14 and wine configured as Windows 98
http://bugs.winehq.org/show_bug.cgi?id=36664 Bug ID: 36664 Summary: Unable to run anything when with kernel version 3.14 and wine configured as Windows 98 Product: Wine Version: 1.7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: doragasu(a)hotmail.com Recently a security issue was fixed on Linux 3.14 kernel for x86_64 (and is being backported to previous versions as well). The security fix unfortunately caused win16 software to stop working, but 32 bit software is supposed to not be affected. This is being discussed here: http://forum.winehq.org/viewtopic.php?f=8&t=22568 The problem is configuring Wine as Windows 9x causes this error to appear even when trying to run 32 bit Windows applications: if you use a kernel with this security flaw fixed and configure Wine in Windows 9x mode, nothing works anymore, not even winecfg. To reproduce the problem you need a Linux box running a 64-bit 3.14 kernel (I'm running up-to-date Archlinux). Then follow these steps: 1.- Create a fresh wine prefix: $ WINEARCH=win32 WINEPREFIX=/home/jalon/wine/test wineboot 2.- Run winecfg: $ WINEPREFIX=/home/jalon/wine/test winecfg 3.- In winecfg, in the default tab (Applications), select "Windows 98" in the "Windows Version" combo box and then click "OK". 4.- Try to run any 32 bit application (e.g. wineboot as in step 1): $ WINEPREFIX=/home/jalon/wine/test wineboot The application will not start, wineboot.exe will be freezed using 100% CPU, and these messages will be printed in the terminal: modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument err:process:__wine_kernel_init boot event wait timed out modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument As winecfg cannot be started anymore in this prefix, the only way to revert it to a working configuration is manually editing the registry and removing the Windows 98 config entry, so this bug is critical because might render existing wine prefixes useless if user sets Windows version to Windows 9x (and maybe also other versions like Windows Me, but I have not tested it). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 doragasu <doragasu(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Unable to run anything when |Unable to run anything with |with kernel version 3.14 |kernel version 3.14 and |and wine configured as |wine configured as Windows |Windows 98 |98 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 doragasu <doragasu(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Unable to run anything with |Unable to run anything with |kernel version 3.14 and |kernel version 3.14 and |wine configured as Windows |wine configured as Windows |98 |9x -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 --- Comment #1 from Bruno Jesus <00cpxxx(a)gmail.com> --- I think this is an UPSTREAM bug. http://lkml.org/lkml/2014/4/14/207 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 --- Comment #2 from Rosanne DiMesio <dimesio(a)earthlink.net> --- The kernel issue is definitely upstream, but I think the problem being reported here is that wineboot, winecfg, regedit, etc. use 16 bit code when the Windows version is set to Windows 98. I don't know if that's a bug or intentional. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=36664 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source CC| |austinenglish(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 --- Comment #3 from oiaohm <oiaohm(a)gmail.com> --- Rosanne DiMesio the reality in the past the 16 bit code was not a issue because the kernel always supported it. In 3.16 and going forwards 16 bit code will require a /proc setting changed in kernel. yes echo 1 > /proc/sys/abi/ldt16 is what you have todo on 3.16 and later to have 16 bit mode. https://lkml.org/lkml/2014/5/7/508. Bruno Jesus yes you are right its a upstream bug. But upstream is declaring it secuirty issue. So its never coming back how we use to use it. Wine has to be altered in design to gracefully handle case of no 16 bit mode and ask user to enable it or reverse windows ME and before mode set. Just like wine currently handles echo 0 > /proc/sys/vm/mmap_min_addr not set on programs that need it. The mmap_min_addr alteration is also due to another security issue. The main bug here is winecfg failed due to using 16 bit code so unable to revert change. This will be true even when 16 bit code support returns to the Linux kernel. If nothing else is change winecfg needs to work. Ok I just got a broken kernel. Windows ME mode is the same. Its all the ME and before are stuffed. I can tell you if you change to Windows 9x mode using apply from winecfg don't close winecfg you can have the fault appear and be able to reverse it. Yes I understand working out if Windows 9x/ME and before applications need 16 mode init will take time. This is why the prime target has to be fixing winecfg so it does not absolute fail. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=36664 --- Comment #4 from Austin English <austinenglish(a)gmail.com> --- (In reply to oiaohm from comment #3)
Rosanne DiMesio the reality in the past the 16 bit code was not a issue because the kernel always supported it. In 3.16 and going forwards 16 bit code will require a /proc setting changed in kernel. yes echo 1 > /proc/sys/abi/ldt16 is what you have todo on 3.16 and later to have 16 bit mode. https://lkml.org/lkml/2014/5/7/508.
Bruno Jesus yes you are right its a upstream bug. But upstream is declaring it secuirty issue. So its never coming back how we use to use it.
I've added a bit of info for this to the FAQ: http://wiki.winehq.org/FAQ -- 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.
https://bugs.winehq.org/show_bug.cgi?id=36664 --- Comment #5 from Rosanne DiMesio <dimesio(a)earthlink.net> --- (In reply to Austin English from comment #4)
I've added a bit of info for this to the FAQ: http://wiki.winehq.org/FAQ
Thanks. I made one change to it: removed the reference to 3.14+ kernels. Ubuntu has backported the change to older versions. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=36664 oiaohm <oiaohm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm(a)gmail.com --- Comment #6 from oiaohm <oiaohm(a)gmail.com> --- /proc/sys/abi/ldt16 I got version wrong its 3.15 where this offically will appear at kernel.org. If you are on a 64 bit system that win16 does not work and its prior to 3.15 you might have /proc/sys/abi/ldt16 if you do enabling it will make it work again. 3.16 is when the hope for the secuirty patch will be done. 32 bit Linux kernels running 16 bit code is secure. The 64 bit mode requires a different fix to a secuity issue than. Still does not change the fact that 3.15 after 16 bit support by kernel is optional on 64 bit systems. Someone without root rights will not be able to change /proc/sys/abi/ldt16 yet they will be able to change winecfg setting on prefix and end up in stuffed. LTS particular versions have had the disabling patch applied some have the /proc/sys/abi/ldt16 applied. As far as I can see no direct kernel.org kernel under 3.15 has the /proc/sys/abi/ldt16 patch applied yet.
From kernel.org 3.15+, 3.14.6+, 3.10.42 +, 3.4.92+ on has /proc/sys/abi/ldt16 in 64 bit mode but if you are running 3.12.21 or 3.2.59 those are busted. Hopefully 3.13.22 and 3.2.60 will have it but we will have to watch.
Just to bewarped 2.6.32.62 has not been patched at all. Basically the faq will have to be updated a few times as the patches are pushed out. In the end there will be two lists. List one will be kernels that contain /proc/sys/abi/ldt16 so 16 bit applications on these 64 bit kernels can be made work with secuirty risks. List two will be kernels that contain espfix64 these are safe to run 16 bit applications but you still have to turn 16 bit on as required. https://lkml.org/lkml/2014/5/4/346 espfix64 is qued for 3.16 and maybe backported to LTS kernels. Why is espfix64 critical it contains the secuirty fix for 16 bit segments for 64 bit kernel. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 Iven Hsu <ivenvd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ivenvd(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tebclause(a)gmail.com --- Comment #7 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 36707 has been marked as a duplicate of this bug. *** -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 --- Comment #8 from oiaohm <oiaohm(a)gmail.com> --- 3.2.60+ is patched to have /proc/sys/abi/ldt16. Only 3.12.21 kernel.org mainline is the only LTS that if you are upto date cannot run win16 binaries. Hopefully 3.12.22 release will have all the current LTS kernels sorted. So at 3.12.22 release I will check if it has patch then update faq. I was wondering why Linux Kernel 2.6.32 was not patching Mid-2014 is its offically end of life. So anyone still running this should be migrating anyhow. I remembered http://wiki.winehq.org/PreloaderPageZeroProblem This is the prior example of wine running into a Linux secuirty fix. It was also crashing when this first change appeared. /proc/sys/abi/ldt16 default state is going to be no 16 bit on 64bit kernel. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 Shmerl <shtetldik(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik(a)gmail.com --- Comment #9 from Shmerl <shtetldik(a)gmail.com> --- I can confirm, this affects 32 bit applications as well (running in Windows 95 or Windows 98 mode). Including ones from Wine itself, such as winecfg! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 Johan Gardhage <johan.gardhage(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36664 --- Comment #10 from Bruno Jesus <00cpxxx(a)gmail.com> --- Alexandre commited a few patches recently, maybe they are related to this issue (like http://source.winehq.org/git/wine.git/commitdiff/b0953a09bdc8d807b6549051c42... ) Please try again in wine-git if possible. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=36664 roger(a)mailinator.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roger(a)mailinator.com --- Comment #11 from roger(a)mailinator.com --- Shouldnt this be fixed by now using up to date kernel? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=36664 doragasu <doragasu(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |UPSTREAM --- Comment #12 from doragasu <doragasu(a)hotmail.com> --- Yes, this problem doesn't show anymore with kernel 3.16+ -- 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.
https://bugs.winehq.org/show_bug.cgi?id=36664 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #13 from Austin English <austinenglish(a)gmail.com> --- (In reply to doragasu from comment #12)
Yes, this problem doesn't show anymore with kernel 3.16+
Fixed upstream, closing. -- 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.
participants (1)
-
wine-bugs＠winehq.org