Extend faq.using to discuss fork failures

[Ryan Johnson]

On 19/08/2011 11:56 AM, Corinna Vinschen wrote:
> On Aug 19 11:33, Ryan Johnson wrote:
>> On 19/08/2011 10:35 AM, Corinna Vinschen wrote:
>>> On Aug 19 09:43, Ryan Johnson wrote:
>>> No, no, Cygwin provides these functions as well.
>> Does that mean Cygwin provides an independent implementation of the
>> functions which should be used instead of the ones from Windows, or
>> just that those functions are among the windows-native calls which
>> cygwin makes available out of the box?
> You're misunderstanding how Cygwin works.  There are no windows-native
> calls which Cygwin makes available.  Cygwin implements its own set
> of spawn functions.  See winsup/cygwin/spawn.cc.
Gotcha. The code comment in process.h just got me confused.

>>>   Apart from that, the
>>> process.h file is a problem since it duplicates the exec function
>>> declarations which are given in sys/unistd.h.  I'll remove them.  If you
>>> want to document them as special Cygwin functions, feel free to add a
>>> spawn.sgml file to winsup/cygwin which can be included into the section
>>> about Cygwin-specific functions, like, for instance, path.sgml or
>>> security.sgml.
>> Whether that makes sense (and what gets written) would depend on the
>> answer to the above, I think.
> On second thought, I agree with Chris.  The spawn functions should not
> be mentioned at all, since they only exist on Windows usually.  We should
> rather implement posix_spawn and posix_spawnp at one point(*).
>
> (*) http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html
That would be ideal, other than the SHTDI part...

>>>> 3. With Vista and later, use peflagsall to set the TS-aware bit on
>>>> all cygwin dlls (see /usr/share/doc/Cygwin/rebase-3.0.1.README,
>>>> reboot needed for changes to take effect). This exploits a side
>>>> effect of address space layout randomization which (ironically)
>>>> causes dlls to nearly always load at the same address.
>>> I'm not sure I ever read about that.  On one hand, the TS-aware flag is
>>> set by gcc 4.x automatically, on the other hand, the TS flag is only
>>> relevant for actual Terminal Servers.
>>> Do you mean the dynamicbase flag, maybe, as described by Chuck at one
>>> point, years ago, on the cygwin-apps list?  Still, I doubt that this
>>> flag has any positive effect, as far as I understand how it works.
>> Oops... up to now I always thought tsaware was the flag that affected ASLR.
>>
>> Reading from this MSDN article [1] clarified things a bit for me.
>> All dynamicbase-marked dlls are randomized (including all system
>> dlls). Unmarked dlls, and those which load them, will not be
>> randomized. So, rebasing dynamicbase dlls would seem to mean little
>> or nothing, and we might be able to get away with not rebasing
>> dynamicbase dlls at all (on Vista and later, of course). In
>> particular, shipping dynamicbase dlls would greatly reduce the need
>> to run rebaseall, because the newly-arrived/clobbered dlls would go
>> right into Windows' ASLR bitmap. Further, dlls which rebaseall can't
>> catch (like those created and dlopened dynamically) might also get a
>> bit of a break. I guess that argues for changing gcc/binutils rather
>> than running peflagsall, tho.
> Hmm, I'm wondering if that's a solution.  AFAIK the number of ASLR DLL
> slots is less than the number of DLLs we're shipping in the distro.
I see. In that case, would it makes sense to have gcc/binutils emit 
dynamicbase dlls by default (to catch cases rebaseall doesn't handle 
well) and then remove the flag for dlls we distribute, depending on 
rebaseall to keep them in line? Only thing is, I don't know how ASLR 
would interact with dlls that appear out of nowhere like that (I guess 
it would work until ASLR bitmap fills?)

Ryan