ASLR breaks cygwin

[Rosen Penev]

Microsoft has a utility called EMET which allows ASLR to be forced on
for each and every process(AlwaysOn) . Unfortunately, this breaks
cygwin. I just made a fresh installation of cygwin64(regular version has
the same problem) and got this at the end:

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-profile.sh exit code 254
base-files-mketc.sh exit code 254
Package: libsasl2_3
libsasl2_3.sh exit code 254
Package: man
man.sh exit code 254

Opening the cygwin terminal results in:

Failed to fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall --help'.

All of this is on Windows 8 64-bit but I remember it also being an issue
with Windows 7. I have not tested 32-bit versions of Windows.

[marco atzeri]

Post by Rosen Penev
Microsoft has a utility called EMET which allows ASLR to be forced on
for each and every process(AlwaysOn) . Unfortunately, this breaks
cygwin.

No surprise as it make fork impossible.

On cygwin all the DLL's have the ASLR flag off
http://cygwin.com/ml/cygwin/2012-04/msg00503.html

Regards
Marco

[Andrey Repin]

Greetings, Rosen Penev!

Post by Rosen Penev
Microsoft has a utility called EMET which allows ASLR to be forced on
for each and every process(AlwaysOn) . Unfortunately, this breaks
cygwin.

-unfortunately
+unsurprisingly

This is to be expected, due to the very definition of Cygwin.

Post by Rosen Penev
I just made a fresh installation of cygwin64(regular version has
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-profile.sh exit code 254
base-files-mketc.sh exit code 254
Package: libsasl2_3
libsasl2_3.sh exit code 254
Package: man
man.sh exit code 254
Failed to fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall --help'.
All of this is on Windows 8 64-bit but I remember it also being an issue
with Windows 7. I have not tested 32-bit versions of Windows.
--
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

--
WBR,
Andrey Repin (***@freemail.ru) 06.06.2013, <20:39>

Sorry for my terrible english...

[Dan Kegel]

Post by Andrey Repin

Post by Rosen Penev
Microsoft has a utility called EMET which allows ASLR to be forced on
for each and every process(AlwaysOn) . Unfortunately, this breaks
cygwin.

-unfortunately
+unsurprisingly
This is to be expected, due to the very definition of Cygwin.

I wonder if we could get them to recognize the parent-child
relationship somehow, and keep the same address space
in the child.

Just kidding. Hell would sooner freeze over.
- Dan

[Warren Young]

Post by Dan Kegel
I wonder if we could get them to recognize the parent-child
relationship somehow, and keep the same address space
in the child.
Just kidding. Hell would sooner freeze over.

I don't know about that. For a long time, they had a bigger conflict of
interest with Cygwin due to SFU/SUA/Interix and the POSIX subsystem.
They announced SUA's doom a couple of years ago[1] and the need for a
separate native POSIX API is gone[2]. I even recall reading on this
list that Microsoft now recommends Cygwin, at least unofficially.

Perhaps Microsoft now has some incentive to create a native fork(2) like
call in their OS that Cygwin could use. (Or something close enough,
like Linux's clone(2).)



[1] http://goo.gl/4hrPg

[2] Presumably, gone with the 90's, when government contracts would
sometimes require POSIX compatibility.

[Corinna Vinschen]

Post by Warren Young

Post by Dan Kegel
I wonder if we could get them to recognize the parent-child
relationship somehow, and keep the same address space
in the child.
Just kidding. Hell would sooner freeze over.

I don't know about that. For a long time, they had a bigger
conflict of interest with Cygwin due to SFU/SUA/Interix and the
POSIX subsystem. They announced SUA's doom a couple of years ago[1]
and the need for a separate native POSIX API is gone[2]. I even
recall reading on this list that Microsoft now recommends Cygwin, at
least unofficially.
Perhaps Microsoft now has some incentive to create a native fork(2)
like call in their OS that Cygwin could use. (Or something close
enough, like Linux's clone(2).)

The problem is not the call. Such a call exists, since Vista even
one with very simple usage. The problem is that this call has
been created for SUA, and some Win32 libs as well as the console
subsystem don't work with this call because there never have been
made provisions for a fork call in the Win32 libs. Chances for
a change are rather low.


Corinna

[Larry Hall (Cygwin)]

Post by Corinna Vinschen

Post by Warren Young

Post by Dan Kegel
I wonder if we could get them to recognize the parent-child
relationship somehow, and keep the same address space
in the child.
Just kidding. Hell would sooner freeze over.

I don't know about that. For a long time, they had a bigger
conflict of interest with Cygwin due to SFU/SUA/Interix and the
POSIX subsystem. They announced SUA's doom a couple of years ago[1]
and the need for a separate native POSIX API is gone[2]. I even
recall reading on this list that Microsoft now recommends Cygwin, at
least unofficially.
Perhaps Microsoft now has some incentive to create a native fork(2)
like call in their OS that Cygwin could use. (Or something close
enough, like Linux's clone(2).)

The problem is not the call. Such a call exists, since Vista even
one with very simple usage. The problem is that this call has
been created for SUA, and some Win32 libs as well as the console
subsystem don't work with this call because there never have been
made provisions for a fork call in the Win32 libs. Chances for
a change are rather low.

So I should put away my ice-skates and pitchforks? Wait, was that
a pun? ;-)

[Corinna Vinschen]

Post by Larry Hall (Cygwin)

Post by Corinna Vinschen

Post by Warren Young

Post by Dan Kegel
I wonder if we could get them to recognize the parent-child
relationship somehow, and keep the same address space
in the child.
Just kidding. Hell would sooner freeze over.

I don't know about that. For a long time, they had a bigger
conflict of interest with Cygwin due to SFU/SUA/Interix and the
POSIX subsystem. They announced SUA's doom a couple of years ago[1]
and the need for a separate native POSIX API is gone[2]. I even
recall reading on this list that Microsoft now recommends Cygwin, at
least unofficially.
Perhaps Microsoft now has some incentive to create a native fork(2)
like call in their OS that Cygwin could use. (Or something close
enough, like Linux's clone(2).)

The problem is not the call. Such a call exists, since Vista even
one with very simple usage. The problem is that this call has
been created for SUA, and some Win32 libs as well as the console
subsystem don't work with this call because there never have been
made provisions for a fork call in the Win32 libs. Chances for
a change are rather low.

So I should put away my ice-skates and pitchforks? Wait, was that
a pun? ;-)

Sorry, I don't get the ice-skates pun.


Corinna

[Eliot Moss]

Post by Corinna Vinschen

Post by Larry Hall (Cygwin)

Post by Dan Kegel
Hell would sooner freeze over.

So I should put away my ice-skates and pitchforks? Wait, was that
a pun? ;-)

Sorry, I don't get the ice-skates pun.

Ice-skates for a frozen place place, pitchforks for hell ....

Regards - Eliot Moss