This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Moses with Cygwin on Windows 7

I don't know if this might interest others, but I have found a thread
explaining the UAC problem at
b5-faff-4de4-be48-f395bf1c519d.  There is an unofficial third-party software
available from to create a white list so that
specific programs can be exempted from UAC prompts. We don't have a computer
with Windows 7 yet, so can't test it out, but I like the idea. 


-----Original Message-----
From: [] On Behalf Of
Eliot Moss
Sent: 08 August 2010 00:34
Subject: Re: Moses with Cygwin on Windows 7

On 8/7/2010 5:23 PM, wrote:

> many thanks for your reply. On why we need cygwin: the language model we
use is IRSTLM. The native
> windows build of Moses does not currently use IRSTLM LMs.

I know next to nothing about Moses, so I'll just trust you on this one!

> I have been reading up a bit about debasing DLLs, and I gather from
> that the purpose is to
avoid either two or more
> DLLs using the same preferred base addresses, or the overheads of
relocation. However, on
> it is suggested that from Vista onwards, it is better to leave this to the
operating systems's ASLR
> (Address space layout randomization) in order to help defeat a
?return-to-libc? attack. Do you agree
> with this? If it is still necessary to do a rebase, what does your script
do that rebaseall doesn't?

The problem is that the address space randomization interferes with how
cygwin support fork().  Suppose a parent process maps library A at
address X, but does not map library B at all.  Then suppose a forked
process is not yet using library A, and ends up mapping library B
at an address that overlaps X.  Then the child reaches a point where
it needs to use library A.  The implementation of cygwin requires
that if a parent and child use the same library, it must be at the
same address.  Therefore the child's mapping attempt will block.
That gives a sense of the scenario.  That may not be the exact
case, but it's like that. Basically, we need to guarantee that all
cygwin dlls map to different preferred places.

Yes, this defeats the OS attempt to defeat a security attack.

My script finds and rebases every dll file that cygwin 'find' can
locate, while rebaseall only does certain directories.  For me,
the difference lies in (at least) some perl-related dlls that are
not where rebaseall looks.

Another important thing is that the distance between preferred
locations needs to be a little bigger than the default for rebase,
on Vista (and Windows 7).  This is an obscure thing that Corinna
found a while back and took me quite a while to locate in old
email threads, but before I set that parameter, rebasing did not
work right for me and after adding that it did.  Maybe they have
changed the default by now, but I don't think so.

> Re UAC prompts: this does look annoying but corporate security regulations
may prevent us from
> turning it off completely. Is there some way to turn it off for individual
programs without using
> third-party software?

That lies outside my expertise.  I just turned it off.

Best wishes -- Eliot Moss

Problem reports:
Unsubscribe info:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]