cygwin stopped working

cygwin stopped working

[Andreas Schiffler]

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

Re: cygwin stopped working

[Doug Henderson]

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

Re: cygwin stopped working

[Andreas Schiffler]

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

Re: cygwin stopped working

[Brian Inglis]

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

Re: cygwin stopped working

[Jostein Berntsen]

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

Re: cygwin stopped working

[Andreas Schiffler]

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

Re: cygwin stopped working

[Bryan Zimmer]

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

Re: cygwin stopped working

[Eliot Moss]

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

Re: cygwin stopped working

[Marco Atzeri]

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

Re: W10 Mandatory ASLR default (was: cygwin stopped working)

[Brian Inglis]

[-- 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

Re: W10 Mandatory ASLR default

[Thomas Wolff]

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

Re: W10 Mandatory ASLR default

[Andreas Schiffler]

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

Re: W10 Mandatory ASLR default

[Brian Inglis]

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

Re: W10 Mandatory ASLR default

[Andreas Schiffler]

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

Re: W10 Mandatory ASLR default

[Achim Gratz]

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

Re: W10 Mandatory ASLR default

[Brian Inglis]

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

Re: cygwin stopped working

[Achim Gratz]

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