* cygwin stopped working @ 2018-02-11 8:18 Andreas Schiffler 2018-02-11 10:42 ` Doug Henderson 0 siblings, 1 reply; 17+ messages in thread From: Andreas Schiffler @ 2018-02-11 8:18 UTC (permalink / raw) To: cygwin Terminal (bash) fails with: Error: Could not fork child process: Resource temporarily unavailable (-1). DLL rebasing may be required; see 'rebaseall / rebase --help'. PC was rebooted and the cygwin was "refreshed". Installer (version 2.884, 32bit) fails with: Package: 0/Perpetual    0p_000_autorebase.dash exit code 127    0p_update-info-dir.dash exit code 127 Package: _/base-cygwin    000-cygwin-post-install.sh exit code 254 Package: _/coreutils    coreutils.sh exit code 254 Package: _/bash    bash.sh exit code 254 Package: _/base-files    base-files-mketc.sh exit code 254    base-files-profile.sh exit code 254 Package: _/ca-certificates    ca-certificates.sh exit code 254 Package: _/man-db    man-db.sh exit code 254 Package: _/mintty    mintty.sh exit code 254 The shell C:\Cygwin\bin\bash.exe can be launched, but any command fails to execute with: bash-4.4$ ls      1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x3922410/0x3962410. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have I do have another version of the cygwin dll file on the system (Plex installation) but that never caused any issues in the past. Thanks for any tips? --Andreas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-11 8:18 cygwin stopped working Andreas Schiffler @ 2018-02-11 10:42 ` Doug Henderson 2018-02-12 1:16 ` Andreas Schiffler 0 siblings, 1 reply; 17+ messages in thread From: Doug Henderson @ 2018-02-11 10:42 UTC (permalink / raw) To: cygwin On 11 February 2018 at 01:18, Andreas Schiffler wrote: > Terminal (bash) fails with: > > Error: Could not fork child process: Resource temporarily unavailable (-1). > DLL rebasing may be required; see 'rebaseall / rebase --help'. > {snip} > bash-4.4$ ls > 1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap > base mismatch detected - 0x3922410/0x3962410. > This problem is probably due to using incompatible versions of the cygwin > DLL. {snip} > I do have another version of the cygwin dll file on the system (Plex > installation) but that never caused any issues in the past. {snip} The method I use is to define CYGWIN_NOWINPATH=1 before I start cygwin. Actually, I set it in my Windows User environment so it is always set for my user. You can find the old windows path as the value of the environment variable ORIGINAL_PATH. Then, when necessary, I add only the previous path components that I require back in my .bash_profile. In my cases,My path looks like: $ echo $PATH /home/USER/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Go/bin:/bin In your case, you may have Plex in your path. Make sure any Plex related directories are not in your cygwin path. A Google (or similar) search for "CYGWIN_NOWINPATH" will find many pages on cygwin.com and stackoverflow.com. HTH Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-11 10:42 ` Doug Henderson @ 2018-02-12 1:16 ` Andreas Schiffler 2018-02-12 2:30 ` Brian Inglis ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Andreas Schiffler @ 2018-02-12 1:16 UTC (permalink / raw) To: cygwin Thanks for the tip, but that didn't seem to have helped. The registry setting CYGWIN_NOWINPATH=1 did not seem to affect the environment as seen in bash. The variable seems to be set: bash-4.4$ set ...snip... COMSPEC='C:\WINDOWS\system32\cmd.exe' CYGWIN_NOWINPATH=1 ...snip but the path variable contains still all the common system locations: bash-4.4$ echo $PATH /cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files (x86)/iis express/PHP/v5.3:/cygdrive/c/Program Files/Common Files/Mic rosoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Common Files/Microsoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Intel/ iCLS Client:/cygdrive/c/Program Files/Intel/iCLS Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:...snip... Manually overriding the PATH variable in bash did not help (presumably because the offending DLL is already loaded): bash-4.4$ export PATH=/usr/local/bin:/usr/bin:/bin bash-4.4$ echo $PATH /usr/local/bin:/usr/bin:/bin bash-4.4$ bash-4.4$ bash-4.4$ ls      0 [main] bash (11276) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x3C52410/0x36F2410. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. On 2/11/2018 2:42 AM, Doug Henderson wrote: > On 11 February 2018 at 01:18, Andreas Schiffler wrote: >> Terminal (bash) fails with: >> >> Error: Could not fork child process: Resource temporarily unavailable (-1). >> DLL rebasing may be required; see 'rebaseall / rebase --help'. >> > {snip} >> bash-4.4$ ls >> 1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap >> base mismatch detected - 0x3922410/0x3962410. >> This problem is probably due to using incompatible versions of the cygwin >> DLL. > {snip} >> I do have another version of the cygwin dll file on the system (Plex >> installation) but that never caused any issues in the past. > {snip} > > > The method I use is to define CYGWIN_NOWINPATH=1 before I start > cygwin. Actually, I set it in my Windows User environment so it is > always set for my user. You can find the old windows path as the value > of the environment variable ORIGINAL_PATH. Then, when necessary, I add > only the previous path components that I require back in my > .bash_profile. In my cases,My path looks like: > > $ echo $PATH > /home/USER/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Go/bin:/bin > > In your case, you may have Plex in your path. Make sure any Plex > related directories are not in your cygwin path. > > A Google (or similar) search for "CYGWIN_NOWINPATH" will find many > pages on cygwin.com and stackoverflow.com. > > HTH > > Doug > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-12 1:16 ` Andreas Schiffler @ 2018-02-12 2:30 ` Brian Inglis 2018-02-12 16:48 ` Jostein Berntsen 2018-02-12 18:16 ` cygwin stopped working Achim Gratz 2 siblings, 0 replies; 17+ messages in thread From: Brian Inglis @ 2018-02-12 2:30 UTC (permalink / raw) To: cygwin On 2018-02-11 18:16, Andreas Schiffler wrote: > On 2/11/2018 2:42 AM, Doug Henderson wrote: >> On 11 February 2018 at 01:18, Andreas Schiffler wrote: >>> Terminal (bash) fails with: >>> Error: Could not fork child process: Resource temporarily unavailable (-1). >>> DLL rebasing may be required; see 'rebaseall / rebase --help'. >>> bash-4.4$ ls >>>       1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap >>> base mismatch detected - 0x3922410/0x3962410. >>> This problem is probably due to using incompatible versions of the cygwin >>> DLL. >>> I do have another version of the cygwin dll file on the system (Plex >>> installation) but that never caused any issues in the past. >> The method I use is to define CYGWIN_NOWINPATH=1 before I start >> cygwin. Actually, I set it in my Windows User environment so it is >> always set for my user. You can find the old windows path as the value >> of the environment variable ORIGINAL_PATH. Then, when necessary, I add >> only the previous path components that I require back in my >> .bash_profile. In my cases,My path looks like: >> $ echo $PATH >> /home/USER/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Go/bin:/bin >> In your case, you may have Plex in your path. Make sure any Plex >> related directories are not in your cygwin path. >> A Google (or similar) search for "CYGWIN_NOWINPATH" will find many >> pages on cygwin.com and stackoverflow.com. > Thanks for the tip, but that didn't seem to have helped.> The registry setting CYGWIN_NOWINPATH=1 did not seem to affect the > environment as seen in bash.> The variable seems to be set:> bash-4.4$ set> COMSPEC='C:\WINDOWS\system32\cmd.exe'> CYGWIN_NOWINPATH=1> but the path variable contains still all the common system locations:> bash-4.4$ echo $PATH> /cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files > (x86)/iis express/PHP/v5.3:/cygdrive/c/Program Files/Common Files/Microsoft > Shared/Windows Live:/cygdrive/c/Program Files (x86)/Common Files/Microsoft > Shared/Windows Live:/cygdrive/c/Program Files (x86)/Intel/iCLS > Client:/cygdrive/c/Program Files/Intel/iCLS > Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:...snip...> Manually overriding the PATH variable in bash did not help (presumably > because the offending DLL is already loaded):> bash-4.4$ export PATH=/usr/local/bin:/usr/bin:/bin> bash-4.4$ echo $PATH> /usr/local/bin:/usr/bin:/bin> bash-4.4$ ls> 0 [main] bash (11276) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap base > mismatch detected - 0x3C52410/0x36F2410.> This problem is probably due to using incompatible versions of the cygwin > DLL.> Search for cygwin1.dll using the Windows Start->Find/Search facility and > delete all but the most recent version. The most recent version *should* > reside in x:\cygwin\bin, where 'x' is the drive on which you have installed > the cygwin distribution. Rebooting is also suggested if you are unable to > find another cygwin DLL. Run in a cmd terminal <CYGWIN_ROOT>\bin\cygcheck bash (or ls) and see if there are any non-Cygwin and non-Windows DLLs from other products' directories in your path that may be interfering. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-12 1:16 ` Andreas Schiffler 2018-02-12 2:30 ` Brian Inglis @ 2018-02-12 16:48 ` Jostein Berntsen 2018-02-13 4:58 ` Andreas Schiffler 2018-02-12 18:16 ` cygwin stopped working Achim Gratz 2 siblings, 1 reply; 17+ messages in thread From: Jostein Berntsen @ 2018-02-12 16:48 UTC (permalink / raw) To: cygwin On 11.02.18,17:16, Andreas Schiffler wrote: > Thanks for the tip, but that didn't seem to have helped. > > The registry setting CYGWIN_NOWINPATH=1 did not seem to affect the > environment as seen in bash. > > The variable seems to be set: > > bash-4.4$ set > ...snip... > COMSPEC='C:\WINDOWS\system32\cmd.exe' > CYGWIN_NOWINPATH=1 > ...snip > > but the path variable contains still all the common system locations: > > bash-4.4$ echo $PATH > /cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files > (x86)/iis express/PHP/v5.3:/cygdrive/c/Program Files/Common Files/Mic > rosoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Common > Files/Microsoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Intel/ > iCLS Client:/cygdrive/c/Program Files/Intel/iCLS > Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:...snip... > > Manually overriding the PATH variable in bash did not help (presumably > because the offending DLL is already loaded): > > bash-4.4$ export PATH=/usr/local/bin:/usr/bin:/bin > bash-4.4$ echo $PATH > /usr/local/bin:/usr/bin:/bin > bash-4.4$ > bash-4.4$ > bash-4.4$ ls >      0 [main] bash (11276) C:\Cygwin\bin\bash.exe: *** fatal error - > cygheap base mismatch detected - 0x3C52410/0x36F2410. > This problem is probably due to using incompatible versions of the cygwin > DLL. > Search for cygwin1.dll using the Windows Start->Find/Search facility > and delete all but the most recent version. The most recent version > *should* > reside in x:\cygwin\bin, where 'x' is the drive on which you have > installed the cygwin distribution. Rebooting is also suggested if you > are unable to find another cygwin DLL. > > > On 2/11/2018 2:42 AM, Doug Henderson wrote: > > On 11 February 2018 at 01:18, Andreas Schiffler wrote: > > > Terminal (bash) fails with: > > > > > > Error: Could not fork child process: Resource temporarily unavailable (-1). > > > DLL rebasing may be required; see 'rebaseall / rebase --help'. > > > > > {snip} > > > bash-4.4$ ls > > > 1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap > > > base mismatch detected - 0x3922410/0x3962410. > > > This problem is probably due to using incompatible versions of the cygwin > > > DLL. > > {snip} > > > I do have another version of the cygwin dll file on the system (Plex > > > installation) but that never caused any issues in the past. > > {snip} > > Run setup.exe for Cugwin once again and let it rebase. Then reboot and see if that works. Jostein -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-12 16:48 ` Jostein Berntsen @ 2018-02-13 4:58 ` Andreas Schiffler 2018-02-14 1:42 ` Bryan Zimmer 2018-02-14 3:25 ` W10 Mandatory ASLR default (was: cygwin stopped working) Brian Inglis 0 siblings, 2 replies; 17+ messages in thread From: Andreas Schiffler @ 2018-02-13 4:58 UTC (permalink / raw) To: cygwin Found the workaround (read: not really a solution as it leaves the system vulnerable, but it unblocks cygwin) - Go to Windows Defender Security Center - Exploit protection settings - Disable System Settings - Force randomization for images (Mandatory ASLR) and Randomize memory allocations (Bottom-up ASLR) from "On by default" to "Off by default" Now setup.exe works and can rebase everything; after that Cygwin Terminal starts as a working shell without problems. @cygwin dev's - It seems one of the windows updates (system is on 1709 build 16299.214) might have changed my ASLR settings to "system wide mandatory" (i.e. see https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ for info) so that the cygwin DLLs don't work correctly anymore (i.e. see old thread about this topic here https://www.cygwin.com/ml/cygwin/2013-06/msg00092.html). This change might have made it into the system as part of the security update for Meltdown+Spectre (I am speculating), but that could explain why my cygwin installation that worked fine before (i.e. mid-2017) stopped working suddenly (beginning 2018). It would be good to device a test for the setup.exe that checks the registry (likely [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]) for this state and alerts the user. @jostein - rebase as part of setup.exe had failed as well (see above). @Achim - that didn't work or do anything (see above). On 2/12/2018 8:49 AM, Jostein Berntsen wrote: > On 11.02.18,17:16, Andreas Schiffler wrote: >> Thanks for the tip, but that didn't seem to have helped. >> >> The registry setting CYGWIN_NOWINPATH=1 did not seem to affect the >> environment as seen in bash. >> >> The variable seems to be set: >> >> bash-4.4$ set >> ...snip... >> COMSPEC='C:\WINDOWS\system32\cmd.exe' >> CYGWIN_NOWINPATH=1 >> ...snip >> >> but the path variable contains still all the common system locations: >> >> bash-4.4$ echo $PATH >> /cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files >> (x86)/iis express/PHP/v5.3:/cygdrive/c/Program Files/Common Files/Mic >> rosoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Common >> Files/Microsoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Intel/ >> iCLS Client:/cygdrive/c/Program Files/Intel/iCLS >> Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:...snip... >> >> Manually overriding the PATH variable in bash did not help (presumably >> because the offending DLL is already loaded): >> >> bash-4.4$ export PATH=/usr/local/bin:/usr/bin:/bin >> bash-4.4$ echo $PATH >> /usr/local/bin:/usr/bin:/bin >> bash-4.4$ >> bash-4.4$ >> bash-4.4$ ls >>      0 [main] bash (11276) C:\Cygwin\bin\bash.exe: *** fatal error - >> cygheap base mismatch detected - 0x3C52410/0x36F2410. >> This problem is probably due to using incompatible versions of the cygwin >> DLL. >> Search for cygwin1.dll using the Windows Start->Find/Search facility >> and delete all but the most recent version. The most recent version >> *should* >> reside in x:\cygwin\bin, where 'x' is the drive on which you have >> installed the cygwin distribution. Rebooting is also suggested if you >> are unable to find another cygwin DLL. >> >> >> On 2/11/2018 2:42 AM, Doug Henderson wrote: >>> On 11 February 2018 at 01:18, Andreas Schiffler wrote: >>>> Terminal (bash) fails with: >>>> >>>> Error: Could not fork child process: Resource temporarily unavailable (-1). >>>> DLL rebasing may be required; see 'rebaseall / rebase --help'. >>>> >>> {snip} >>>> bash-4.4$ ls >>>> 1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - cygheap >>>> base mismatch detected - 0x3922410/0x3962410. >>>> This problem is probably due to using incompatible versions of the cygwin >>>> DLL. >>> {snip} >>>> I do have another version of the cygwin dll file on the system (Plex >>>> installation) but that never caused any issues in the past. >>> {snip} >>> > Run setup.exe for Cugwin once again and let it rebase. Then reboot and > see if that works. > > Jostein > > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-13 4:58 ` Andreas Schiffler @ 2018-02-14 1:42 ` Bryan Zimmer 2018-02-14 7:53 ` Eliot Moss 2018-02-14 8:49 ` Marco Atzeri 2018-02-14 3:25 ` W10 Mandatory ASLR default (was: cygwin stopped working) Brian Inglis 1 sibling, 2 replies; 17+ messages in thread From: Bryan Zimmer @ 2018-02-14 1:42 UTC (permalink / raw) To: cygwin I have been following this thread closely as I have a similar problem. It only differs in that mintty, which I use to start bash, fails completely. It tells me that it cannot fork, that the problem could be that I have more than 1 cygwin1.dll, that I should run rebaseall or rebase --help. Unfortunately all cygwin processes have the same problem. Even a fresh, clean re-installation of all of cygwin left me with the same problem. On Mon, Feb 12, 2018 at 10:58 PM, Andreas Schiffler <aschiffler@ferzkopp.net > wrote: > Found the workaround (read: not really a solution as it leaves the system > vulnerable, but it unblocks cygwin) > - Go to Windows Defender Security Center - Exploit protection settings > - Disable System Settings - Force randomization for images (Mandatory > ASLR) and Randomize memory allocations (Bottom-up ASLR) from "On by > default" to "Off by default" > > Now setup.exe works and can rebase everything; after that Cygwin Terminal > starts as a working shell without problems. > > @cygwin dev's - It seems one of the windows updates (system is on 1709 > build 16299.214) might have changed my ASLR settings to "system wide > mandatory" (i.e. see https://blogs.technet.microsof > t.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ for info) > so that the cygwin DLLs don't work correctly anymore (i.e. see old thread > about this topic here https://www.cygwin.com/ml/cygw > in/2013-06/msg00092.html). This change might have made it into the system > as part of the security update for Meltdown+Spectre (I am speculating), but > that could explain why my cygwin installation that worked fine before (i.e. > mid-2017) stopped working suddenly (beginning 2018). It would be good to > device a test for the setup.exe that checks the registry (likely > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session > Manager\kernel]) for this state and alerts the user. > @jostein - rebase as part of setup.exe had failed as well (see above). > @Achim - that didn't work or do anything (see above). > > > On 2/12/2018 8:49 AM, Jostein Berntsen wrote: > >> On 11.02.18,17:16, Andreas Schiffler wrote: >> >>> Thanks for the tip, but that didn't seem to have helped. >>> >>> The registry setting CYGWIN_NOWINPATH=1 did not seem to affect the >>> environment as seen in bash. >>> >>> The variable seems to be set: >>> >>> bash-4.4$ set >>> ...snip... >>> COMSPEC='C:\WINDOWS\system32\cmd.exe' >>> CYGWIN_NOWINPATH=1 >>> ...snip >>> >>> but the path variable contains still all the common system locations: >>> >>> bash-4.4$ echo $PATH >>> /cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files >>> (x86)/iis express/PHP/v5.3:/cygdrive/c/Program Files/Common Files/Mic >>> rosoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Common >>> Files/Microsoft Shared/Windows Live:/cygdrive/c/Program Files >>> (x86)/Intel/ >>> iCLS Client:/cygdrive/c/Program Files/Intel/iCLS >>> Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:...snip... >>> >>> Manually overriding the PATH variable in bash did not help (presumably >>> because the offending DLL is already loaded): >>> >>> bash-4.4$ export PATH=/usr/local/bin:/usr/bin:/bin >>> bash-4.4$ echo $PATH >>> /usr/local/bin:/usr/bin:/bin >>> bash-4.4$ >>> bash-4.4$ >>> bash-4.4$ ls >>> 0 [main] bash (11276) C:\Cygwin\bin\bash.exe: *** fatal error - >>> cygheap base mismatch detected - 0x3C52410/0x36F2410. >>> This problem is probably due to using incompatible versions of the cygwin >>> DLL. >>> Search for cygwin1.dll using the Windows Start->Find/Search facility >>> and delete all but the most recent version. The most recent version >>> *should* >>> reside in x:\cygwin\bin, where 'x' is the drive on which you have >>> installed the cygwin distribution. Rebooting is also suggested if you >>> are unable to find another cygwin DLL. >>> >>> >>> On 2/11/2018 2:42 AM, Doug Henderson wrote: >>> >>>> On 11 February 2018 at 01:18, Andreas Schiffler wrote: >>>> >>>>> Terminal (bash) fails with: >>>>> >>>>> Error: Could not fork child process: Resource temporarily unavailable >>>>> (-1). >>>>> DLL rebasing may be required; see 'rebaseall / rebase --help'. >>>>> >>>>> {snip} >>>> >>>>> bash-4.4$ ls >>>>> 1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - >>>>> cygheap >>>>> base mismatch detected - 0x3922410/0x3962410. >>>>> This problem is probably due to using incompatible versions of the >>>>> cygwin >>>>> DLL. >>>>> >>>> {snip} >>>> >>>>> I do have another version of the cygwin dll file on the system (Plex >>>>> installation) but that never caused any issues in the past. >>>>> >>>> {snip} >>>> >>>> Run setup.exe for Cugwin once again and let it rebase. Then reboot and >> see if that works. >> >> Jostein >> >> >> >> -- >> Problem reports: http://cygwin.com/problems.html >> FAQ: http://cygwin.com/faq/ >> Documentation: http://cygwin.com/docs.html >> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >> >> >> > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-14 1:42 ` Bryan Zimmer @ 2018-02-14 7:53 ` Eliot Moss 2018-02-14 8:49 ` Marco Atzeri 1 sibling, 0 replies; 17+ messages in thread From: Eliot Moss @ 2018-02-14 7:53 UTC (permalink / raw) To: cygwin On 2/13/2018 8:41 PM, Bryan Zimmer wrote: > I have been following this thread closely as I have a similar problem. It > only differs in that mintty, which I use to start bash, fails completely. > It tells me that it cannot fork, that the problem could be that I have more > than 1 cygwin1.dll, that I should run rebaseall or rebase --help. > Unfortunately all cygwin processes have the same problem. Even a fresh, > clean re-installation of all of cygwin left me with the same problem. I would assume you have - but just checking - have you looked really hard for a second cygwin1.dll lurking somewhere? Reinstalling, etc., won't fix that ... Regards - Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-14 1:42 ` Bryan Zimmer 2018-02-14 7:53 ` Eliot Moss @ 2018-02-14 8:49 ` Marco Atzeri 1 sibling, 0 replies; 17+ messages in thread From: Marco Atzeri @ 2018-02-14 8:49 UTC (permalink / raw) To: cygwin No TOP post please On 14/02/2018 02:41, Bryan Zimmer wrote: > I have been following this thread closely as I have a similar problem. It > only differs in that mintty, which I use to start bash, fails completely. > It tells me that it cannot fork, that the problem could be that I have more > than 1 cygwin1.dll, that I should run rebaseall or rebase --help. > Unfortunately all cygwin processes have the same problem. Even a fresh, > clean re-installation of all of cygwin left me with the same problem. > Have you checked, what Andreas did ? > On Mon, Feb 12, 2018 at 10:58 PM, Andreas Schiffler >> wrote: > >> Found the workaround (read: not really a solution as it leaves the system >> vulnerable, but it unblocks cygwin) >> - Go to Windows Defender Security Center - Exploit protection settings >> - Disable System Settings - Force randomization for images (Mandatory >> ASLR) and Randomize memory allocations (Bottom-up ASLR) from "On by >> default" to "Off by default" Windows Defender is a know problem for fork https://cygwin.com/faq/faq.html#faq.using.bloda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: W10 Mandatory ASLR default (was: cygwin stopped working) 2018-02-13 4:58 ` Andreas Schiffler 2018-02-14 1:42 ` Bryan Zimmer @ 2018-02-14 3:25 ` Brian Inglis 2018-02-14 7:17 ` W10 Mandatory ASLR default Thomas Wolff 1 sibling, 1 reply; 17+ messages in thread From: Brian Inglis @ 2018-02-14 3:25 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2770 bytes --] On 2018-02-12 21:58, Andreas Schiffler wrote: > Found the workaround (read: not really a solution as it leaves the system > vulnerable, but it unblocks cygwin) > - Go to Windows Defender Security Center - Exploit protection settings > - Disable System Settings - Force randomization for images (Mandatory ASLR) and > Randomize memory allocations (Bottom-up ASLR) from "On by default" to "Off by > default" > > Now setup.exe works and can rebase everything; after that Cygwin Terminal starts > as a working shell without problems. > > @cygwin dev's - It seems one of the windows updates (system is on 1709 build > 16299.214) might have changed my ASLR settings to "system wide mandatory" (i.e. > see > https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ > for info) so that the cygwin DLLs don't work correctly anymore (i.e. see old > thread about this topic here > https://www.cygwin.com/ml/cygwin/2013-06/msg00092.html). > This change might have made it into the system as part of the security update > for Meltdown+Spectre (I am speculating), but that could explain why my cygwin > installation that worked fine before (i.e. mid-2017) stopped working suddenly > (beginning 2018). It would be good to devize a test for the setup.exe that > checks the registry (likely > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]) > for this state and alerts the user. I'm on W10 Home 1709/16299.192 (slightly older). Under Windows Defender Security Center/App & browser control/Exploit protection/Exploit protection settings/System settings/Force randomization for images (Mandatory ASLR) - "Force relocation of images not compiled with /DYNAMICBASE" is "Off by default", whereas Randomize memory allocations (Bottom-up ASLR) - "Randomize locations for virtual memory allocations." and all other settings are "On by default". Under Windows Defender Security Center/App & browser control/Exploit protection/Exploit protection settings/Program settings various .exes have 0-2 system overrides of settings. I used the Export settings selection at the bottom to export the settings, which use the implied System settings defaults, and include the Program settings system overrides shown in the attached xml file. It may be useful if you could export your default and updated settings for comparison and information. It would be nice if one of the project volunteers with Windows threat mitigation knowledge could look at these, to see if there is a better approach. I expect to get updated the next time I restart, as I have been seeing notifications to that effect, and will not be surprised if my system startup Cygwin shell scripts fail. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada [-- Attachment #2: ExploitProtectionProgramSettingsSystemOverrides.xml --] [-- Type: text/xml, Size: 3211 bytes --] <?xml version="1.0" encoding="UTF-8"?> <root> <SystemConfig></SystemConfig> <AppConfig Executable="DevicesFlow.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> <AppConfig Executable="ExtExport.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="ie4uinit.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="ieinstal.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="ielowutil.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="ieUnatt.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="iexplore.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="MiracastView.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> <AppConfig Executable="mscorsvw.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> <AppConfig Executable="msfeedssync.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="mshta.exe"> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false"></ASLR> </AppConfig> <AppConfig Executable="ngen.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> <AppConfig Executable="ngentask.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> <AppConfig Executable="PresentationHost.exe"> <DEP Enable="true" EmulateAtlThunks="false" OverrideDEP="false"></DEP> <ASLR Enable="true" ForceRelocateImages="false" OverrideForceRelocateImages="false" BottomUp="true" HighEntropy="true" OverrideBottomUp="false"></ASLR> <SEHOP Enable="true" TelemetryOnly="false" OverrideSEHOP="false"></SEHOP> <Heap TerminateOnError="true" OverrideHeap="false"></Heap> </AppConfig> <AppConfig Executable="PrintDialog.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> <AppConfig Executable="PrintIsolationHost.exe"></AppConfig> <AppConfig Executable="runtimebroker.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> <AppConfig Executable="splwow64.exe"></AppConfig> <AppConfig Executable="spoolsv.exe"></AppConfig> <AppConfig Executable="svchost.exe"></AppConfig> <AppConfig Executable="SystemSettings.exe"> <ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints> </AppConfig> </root> [-- Attachment #3: Type: text/plain, Size: 219 bytes --] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: W10 Mandatory ASLR default 2018-02-14 3:25 ` W10 Mandatory ASLR default (was: cygwin stopped working) Brian Inglis @ 2018-02-14 7:17 ` Thomas Wolff 2018-02-14 7:36 ` Andreas Schiffler 0 siblings, 1 reply; 17+ messages in thread From: Thomas Wolff @ 2018-02-14 7:17 UTC (permalink / raw) To: cygwin Am 14.02.2018 um 04:25 schrieb Brian Inglis: > On 2018-02-12 21:58, Andreas Schiffler wrote: >> Found the workaround (read: not really a solution as it leaves the system >> vulnerable, but it unblocks cygwin) >> - Go to Windows Defender Security Center - Exploit protection settings >> - Disable System Settings - Force randomization for images (Mandatory ASLR) and >> Randomize memory allocations (Bottom-up ASLR) from "On by default" to "Off by >> default" >> >> Now setup.exe works and can rebase everything; after that Cygwin Terminal starts >> as a working shell without problems. >> >> @cygwin dev's - It seems one of the windows updates (system is on 1709 build >> 16299.214) might have changed my ASLR settings to "system wide mandatory" (i.e. >> see >> https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ >> for info) so that the cygwin DLLs don't work correctly anymore (i.e. see old >> thread about this topic here >> https://www.cygwin.com/ml/cygwin/2013-06/msg00092.html). >> This change might have made it into the system as part of the security update >> for Meltdown+Spectre (I am speculating), but that could explain why my cygwin >> installation that worked fine before (i.e. mid-2017) stopped working suddenly >> (beginning 2018). It would be good to devize a test for the setup.exe that >> checks the registry (likely >> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]) >> for this state and alerts the user. > I'm on W10 Home 1709/16299.192 (slightly older). > > Under Windows Defender Security Center/App & browser control/Exploit > protection/Exploit protection settings/System settings/Force randomization for > images (Mandatory ASLR) - "Force relocation of images not compiled with > /DYNAMICBASE" is "Off by default", whereas Randomize memory allocations > (Bottom-up ASLR) - "Randomize locations for virtual memory allocations." and all > other settings are "On by default". > > Under Windows Defender Security Center/App & browser control/Exploit > protection/Exploit protection settings/Program settings various .exes have 0-2 > system overrides of settings. > > I used the Export settings selection at the bottom to export the settings, which > use the implied System settings defaults, and include the Program settings > system overrides shown in the attached xml file. > > It may be useful if you could export your default and updated settings for > comparison and information. > It would be nice if one of the project volunteers with Windows threat mitigation > knowledge could look at these, to see if there is a better approach. > > I expect to get updated the next time I restart, as I have been seeing > notifications to that effect, and will not be surprised if my system startup > Cygwin shell scripts fail. I guess Andreas' suggestion is confirmed by https://github.com/mintty/wsltty/issues/6#issuecomment-361281467 Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: W10 Mandatory ASLR default 2018-02-14 7:17 ` W10 Mandatory ASLR default Thomas Wolff @ 2018-02-14 7:36 ` Andreas Schiffler 2018-02-16 6:41 ` Brian Inglis 0 siblings, 1 reply; 17+ messages in thread From: Andreas Schiffler @ 2018-02-14 7:36 UTC (permalink / raw) To: cygwin Here is the registry state: Mandatory ASLR off Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] "MitigationOptions"=hex:00,02,22,00,00,00,00,00,00,00,00,00,00,00,00,00 Mandatory ASLR on Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] "MitigationOptions"=hex:00,01,21,00,00,00,00,00,00,00,00,00,00,00,00,00 On 2/13/2018 11:17 PM, Thomas Wolff wrote: > Am 14.02.2018 um 04:25 schrieb Brian Inglis: >> On 2018-02-12 21:58, Andreas Schiffler wrote: >>> Found the workaround (read: not really a solution as it leaves the >>> system >>> vulnerable, but it unblocks cygwin) >>> - Go to Windows Defender Security Center - Exploit protection settings >>> - Disable System Settings - Force randomization for images >>> (Mandatory ASLR) and >>> Randomize memory allocations (Bottom-up ASLR) from "On by default" >>> to "Off by >>> default" >>> >>> Now setup.exe works and can rebase everything; after that Cygwin >>> Terminal starts >>> as a working shell without problems. >>> >>> @cygwin dev's - It seems one of the windows updates (system is on >>> 1709 build >>> 16299.214) might have changed my ASLR settings to "system wide >>> mandatory" (i.e. >>> see >>> https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ >>> >>> for info) so that the cygwin DLLs don't work correctly anymore (i.e. >>> see old >>> thread about this topic here >>> https://www.cygwin.com/ml/cygwin/2013-06/msg00092.html). >>> This change might have made it into the system as part of the >>> security update >>> for Meltdown+Spectre (I am speculating), but that could explain why >>> my cygwin >>> installation that worked fine before (i.e. mid-2017) stopped working >>> suddenly >>> (beginning 2018). It would be good to devize a test for the >>> setup.exe that >>> checks the registry (likely >>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session >>> Manager\kernel]) >>> for this state and alerts the user. >> I'm on W10 Home 1709/16299.192 (slightly older). >> >> Under Windows Defender Security Center/App & browser control/Exploit >> protection/Exploit protection settings/System settings/Force >> randomization for >> images (Mandatory ASLR) - "Force relocation of images not compiled with >> /DYNAMICBASE" is "Off by default", whereas Randomize memory allocations >> (Bottom-up ASLR) - "Randomize locations for virtual memory >> allocations." and all >> other settings are "On by default". >> >> Under Windows Defender Security Center/App & browser control/Exploit >> protection/Exploit protection settings/Program settings various .exes >> have 0-2 >> system overrides of settings. >> >> I used the Export settings selection at the bottom to export the >> settings, which >> use the implied System settings defaults, and include the Program >> settings >> system overrides shown in the attached xml file. >> >> It may be useful if you could export your default and updated >> settings for >> comparison and information. >> It would be nice if one of the project volunteers with Windows threat >> mitigation >> knowledge could look at these, to see if there is a better approach. >> >> I expect to get updated the next time I restart, as I have been seeing >> notifications to that effect, and will not be surprised if my system >> startup >> Cygwin shell scripts fail. > I guess Andreas' suggestion is confirmed by > https://github.com/mintty/wsltty/issues/6#issuecomment-361281467 > Thomas > > -- > Problem reports:Â Â Â Â Â Â http://cygwin.com/problems.html > FAQ:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â http://cygwin.com/faq/ > Documentation:Â Â Â Â Â Â Â Â http://cygwin.com/docs.html > Unsubscribe info:Â Â Â Â Â http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: W10 Mandatory ASLR default 2018-02-14 7:36 ` Andreas Schiffler @ 2018-02-16 6:41 ` Brian Inglis 2018-02-18 19:43 ` Andreas Schiffler 2018-02-18 20:07 ` Achim Gratz 0 siblings, 2 replies; 17+ messages in thread From: Brian Inglis @ 2018-02-16 6:41 UTC (permalink / raw) To: cygwin On 2018-02-14 00:36, Andreas Schiffler wrote: > On 2/13/2018 11:17 PM, Thomas Wolff wrote: >> Am 14.02.2018 um 04:25 schrieb Brian Inglis: >>> On 2018-02-12 21:58, Andreas Schiffler wrote: >>>> Found the workaround (read: not really a solution as it leaves the system >>>> vulnerable, but it unblocks cygwin) >>>> - Go to Windows Defender Security Center - Exploit protection settings >>>> - Disable System Settings - Force randomization for images (Mandatory ASLR) and >>>> Randomize memory allocations (Bottom-up ASLR) from "On by default" to "Off by >>>> default" >>>> >>>> Now setup.exe works and can rebase everything; after that Cygwin Terminal >>>> starts as a working shell without problems. >>>> @cygwin dev's - It seems one of the windows updates (system is on 1709 build >>>> 16299.214) might have changed my ASLR settings to "system wide mandatory" (i.e. >>>> see >>>> https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ >>>> for info) so that the cygwin DLLs don't work correctly anymore (i.e. see old >>>> thread about this topic here >>>> https://www.cygwin.com/ml/cygwin/2013-06/msg00092.html). >>>> It would be good to devize a test for the setup.exe that >>>> checks the registry (likely >>>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]) >>>> for this state and alerts the user. >>> I'm on W10 Home 1709/16299.192 (slightly older). >>> Under Windows Defender Security Center/App & browser control/Exploit >>> protection/Exploit protection settings/System settings/Force randomization for >>> images (Mandatory ASLR) - "Force relocation of images not compiled with >>> /DYNAMICBASE" is "Off by default", whereas Randomize memory allocations >>> (Bottom-up ASLR) - "Randomize locations for virtual memory allocations." and all >>> other settings are "On by default". >>> Under Windows Defender Security Center/App & browser control/Exploit >>> protection/Exploit protection settings/Program settings various .exes have 0-2 >>> system overrides of settings. >>> It would be nice if one of the project volunteers with Windows threat mitigation >>> knowledge could look at these, to see if there is a better approach. >> I guess Andreas' suggestion is confirmed by >> https://github.com/mintty/wsltty/issues/6#issuecomment-361281467 > Here is the registry state: > Mandatory ASLR off > Windows Registry Editor Version 5.00 > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] > "MitigationOptions"=hex:00,02,22,00,00,00,00,00,00,00,00,00,00,00,00,00 > Mandatory ASLR on > Windows Registry Editor Version 5.00 > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] > "MitigationOptions"=hex:00,01,21,00,00,00,00,00,00,00,00,00,00,00,00,00 Could setup be updated to reset Mandatory ASLR if the reg keys exist, or an /etc/postinstall/[0z]p_disable_mandatory_aslr.sh script do a check and reset? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: W10 Mandatory ASLR default 2018-02-16 6:41 ` Brian Inglis @ 2018-02-18 19:43 ` Andreas Schiffler 2018-02-18 20:07 ` Achim Gratz 1 sibling, 0 replies; 17+ messages in thread From: Andreas Schiffler @ 2018-02-18 19:43 UTC (permalink / raw) To: cygwin I'd say add a check and post a warning would the best solution. A setup script shouldn't modify a users security setup, and even if the script were to reset the settings they wouldn't be active until after a reboot. On 2/15/2018 10:41 PM, Brian Inglis wrote: > On 2018-02-14 00:36, Andreas Schiffler wrote: >> On 2/13/2018 11:17 PM, Thomas Wolff wrote: >>> Am 14.02.2018 um 04:25 schrieb Brian Inglis: >>>> On 2018-02-12 21:58, Andreas Schiffler wrote: >>>>> Found the workaround (read: not really a solution as it leaves the system >>>>> vulnerable, but it unblocks cygwin) >>>>> - Go to Windows Defender Security Center - Exploit protection settings >>>>> - Disable System Settings - Force randomization for images (Mandatory ASLR) and >>>>> Randomize memory allocations (Bottom-up ASLR) from "On by default" to "Off by >>>>> default" >>>>> >>>>> Now setup.exe works and can rebase everything; after that Cygwin Terminal >>>>> starts as a working shell without problems. >>>>> @cygwin dev's - It seems one of the windows updates (system is on 1709 build >>>>> 16299.214) might have changed my ASLR settings to "system wide mandatory" (i.e. >>>>> see >>>>> https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ >>>>> for info) so that the cygwin DLLs don't work correctly anymore (i.e. see old >>>>> thread about this topic here >>>>> https://www.cygwin.com/ml/cygwin/2013-06/msg00092.html). >>>>> It would be good to devize a test for the setup.exe that >>>>> checks the registry (likely >>>>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]) >>>>> for this state and alerts the user. >>>> I'm on W10 Home 1709/16299.192 (slightly older). >>>> Under Windows Defender Security Center/App & browser control/Exploit >>>> protection/Exploit protection settings/System settings/Force randomization for >>>> images (Mandatory ASLR) - "Force relocation of images not compiled with >>>> /DYNAMICBASE" is "Off by default", whereas Randomize memory allocations >>>> (Bottom-up ASLR) - "Randomize locations for virtual memory allocations." and all >>>> other settings are "On by default". >>>> Under Windows Defender Security Center/App & browser control/Exploit >>>> protection/Exploit protection settings/Program settings various .exes have 0-2 >>>> system overrides of settings. >>>> It would be nice if one of the project volunteers with Windows threat mitigation >>>> knowledge could look at these, to see if there is a better approach. >>> I guess Andreas' suggestion is confirmed by >>> https://github.com/mintty/wsltty/issues/6#issuecomment-361281467 >> Here is the registry state: >> Mandatory ASLR off >> Windows Registry Editor Version 5.00 >> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] >> "MitigationOptions"=hex:00,02,22,00,00,00,00,00,00,00,00,00,00,00,00,00 >> Mandatory ASLR on >> Windows Registry Editor Version 5.00 >> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] >> "MitigationOptions"=hex:00,01,21,00,00,00,00,00,00,00,00,00,00,00,00,00 > Could setup be updated to reset Mandatory ASLR if the reg keys exist, or an > /etc/postinstall/[0z]p_disable_mandatory_aslr.sh script do a check and reset? > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: W10 Mandatory ASLR default 2018-02-16 6:41 ` Brian Inglis 2018-02-18 19:43 ` Andreas Schiffler @ 2018-02-18 20:07 ` Achim Gratz 2018-02-18 22:40 ` Brian Inglis 1 sibling, 1 reply; 17+ messages in thread From: Achim Gratz @ 2018-02-18 20:07 UTC (permalink / raw) To: cygwin Brian Inglis writes: > Could setup be updated to reset Mandatory ASLR if the reg keys exist, or an > /etc/postinstall/[0z]p_disable_mandatory_aslr.sh script do a check and reset? Both methods would likely be considered hostile by those who are most likely set these keys and in fact I'd expect them to be re-set by group policy even if they were changeable in any corporate environment. Note that forcing mandatory ASLR on non-ASLR-aware executables is not the default on Windows 10, although beta-testers might have got pushed such a setting, based on what was reported here and elsewhere. Anyone who sets this option on his own box without understanding what it really does gets to keep the broken pieces. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: W10 Mandatory ASLR default 2018-02-18 20:07 ` Achim Gratz @ 2018-02-18 22:40 ` Brian Inglis 0 siblings, 0 replies; 17+ messages in thread From: Brian Inglis @ 2018-02-18 22:40 UTC (permalink / raw) To: cygwin On 2018-02-18 13:07, Achim Gratz wrote: > Brian Inglis writes: >> Could setup be updated to reset Mandatory ASLR if the reg keys exist, or an >> /etc/postinstall/[0z]p_disable_mandatory_aslr.sh script do a check and reset? > > Both methods would likely be considered hostile by those who are most > likely set these keys and in fact I'd expect them to be re-set by group > policy even if they were changeable in any corporate environment. Note > that forcing mandatory ASLR on non-ASLR-aware executables is not the > default on Windows 10, although beta-testers might have got pushed such > a setting, based on what was reported here and elsewhere. Anyone who > sets this option on his own box without understanding what it really > does gets to keep the broken pieces. My concern is for those who do not set it themselves or are unaware of the impact on Cygwin. Cygwin does not set dynamic base in exes and dlls, so should not be affected unless Mandatory ASLR is set: https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ W7 EMET and EoL 2018 July - upgrade for any future patches: https://technet.microsoft.com/en-us/security/jj653751 I'll be watching carefully after my next W10 Home standard restart, to see if it changes as part of Spectre/Meltdown mitigation. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cygwin stopped working 2018-02-12 1:16 ` Andreas Schiffler 2018-02-12 2:30 ` Brian Inglis 2018-02-12 16:48 ` Jostein Berntsen @ 2018-02-12 18:16 ` Achim Gratz 2 siblings, 0 replies; 17+ messages in thread From: Achim Gratz @ 2018-02-12 18:16 UTC (permalink / raw) To: cygwin Andreas Schiffler writes: > Thanks for the tip, but that didn't seem to have helped. > > The registry setting CYGWIN_NOWINPATH=1 did not seem to affect the > environment as seen in bash. You need to start bash so that it actually processes /etc/profile for this to work (most simply, start it as a login shell). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-02-18 22:40 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-11 8:18 cygwin stopped working Andreas Schiffler 2018-02-11 10:42 ` Doug Henderson 2018-02-12 1:16 ` Andreas Schiffler 2018-02-12 2:30 ` Brian Inglis 2018-02-12 16:48 ` Jostein Berntsen 2018-02-13 4:58 ` Andreas Schiffler 2018-02-14 1:42 ` Bryan Zimmer 2018-02-14 7:53 ` Eliot Moss 2018-02-14 8:49 ` Marco Atzeri 2018-02-14 3:25 ` W10 Mandatory ASLR default (was: cygwin stopped working) Brian Inglis 2018-02-14 7:17 ` W10 Mandatory ASLR default Thomas Wolff 2018-02-14 7:36 ` Andreas Schiffler 2018-02-16 6:41 ` Brian Inglis 2018-02-18 19:43 ` Andreas Schiffler 2018-02-18 20:07 ` Achim Gratz 2018-02-18 22:40 ` Brian Inglis 2018-02-12 18:16 ` cygwin stopped working Achim Gratz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).