* Re: Potential BLODA issue with commercial file encryption tool
2017-11-07 18:48 Potential BLODA issue with commercial file encryption tool Weiner Michael
@ 2017-11-08 18:24 ` Brian Inglis
0 siblings, 0 replies; 2+ messages in thread
From: Brian Inglis @ 2017-11-08 18:24 UTC (permalink / raw)
To: cygwin
On 2017-11-07 11:48, Weiner Michael wrote:
> there seems to be a BLODA issue between Cygwin and a commercial file
> encryption tool named "fideAS file enterprise". Since this tool was upgraded
> from version 6.4.0.12 to 7.1.0.8 on some computers, errors like the
> following started to occur. Some applications (like tmux) always reproducibly
> fail to start, others (like bash) sometimes succeed and sometimes do not,
> depending on the circumstances that I have not figured out exactly yet.
> --- cut ---
> $ tmux
> 0 [main] tmux 8916 fork: child 9156 - died waiting for dll loading, errno 11
> --- cut ---
> In the DLL view of Sysinternals Process Explorer, I see a file named
> "asCryptoFilter64.dll" being loaded into bash.exe, mintty.exe and others.
> Note that there are two processes running related to fideAS, namely
> "ffPrivateAgent.exe" and "loadFilter.exe" . Killing them does not prevent
> the aforementioned DLL from being loaded into newly created processes, even
> if the process creation takes place after killing the two processes (how does
> this work, by the way?). The error also remains after killing these two
> processes.
> Note that when the Cygwin terminal is run as administrator,
> asCryptoFilter64.dll does not appear in the Process Explorer DLL list, and
> tmux works. I just figured that out right away when composing this mail.
> What I have tried so far:
> * execute /usr/bin/rebase-trigger full, then re-run setup-x86_64.exe
> effect: tmux makes the terminal window hang when called.
> (I tried rebasing twice, both times led to the same result)
> * our IT department was in touch with the supplier of fideAS file enterprise.
> I was told that the Cygwin stack memory is too small (only approx. 1.8MB),
> and that usual applications have around 10MB. I did not have any context
> information, so I did - basically without knowing what is going on behind the
> scenes -:
> --- cut ---
> 1) create copy of cygwin directory to /cygdrive/d/cygwin64_copy in Windows Explorer
> 2) find /cygdrive/d/cygwin64_copy \( -iname '*.exe' -o '*.dll' \) -exec peflags -X10485760 -x104857600 {} \;
> 3) move original cygwin directory to /cygdrive/d/cygwin64_orig and /cygdrive/d/cygwin64_copy to original directory
> 4) try running tmux: no effect
> --- cut ---
> This did not have any evident effect. I was told that re-compiling Cygwin
> with a compiler option to increase the stack size (I assume this would be
> -Wl,--stack,<size>) could solve the issue, but when the build process hung
> for several hours, I did not try this any further yet. Do you consider this
> an option worth trying?
> * I set the environment variable CYGWIN to detect_bloda, but did not learn
> anything from that (is this still active?
> https://cygwin.com/ml/cygwin-cvs/2016-q2/msg00135.html suggests it is not)
> Note that the supplier has been working on this for more than a month now,
> but we neither have an ETA, nor feedback whether this can be fixed at all...
> Does maybe someone here have an idea how to proceed any further?
As previously discussed on the mailing list thread containing
https://sourceware.org/ml/cygwin/2013-08/msg00322.html
Cygwin reserves 2MB initial allocated stack space, double the 1MB initial
allocated stack space reserved by Windows programs.
Windows allocates guard pages below the committed stack limit, and auto-extends
the committed stack when stored to below the limit (at least it should only
extend on stores, to provide some protection against programs reading from
uncommitted stack space pages before they've been stored in, or any access to
some wild address below that).
If their product has a problem and requires more user stack space, they should
be able to write to each page below the current limit to safely extend the
available space before use.
Each program, process, dll, and thread gets its own stack space allocated, so
I'm unsure we're getting the whole explanation, including why they need 10MB of
stack space during file en-/decryption, why they're not spawning their own
thread, and allocating their own stack space, if they need more than some
programs provide.
You can see the pattern of per thread allocations below, with 2MB/thread total -
===p marks allocated but uncommitted private space; rw-g marks 4 pages guard
space; and rw-p marks currently committed private stack space:
$ fgrep stack /proc/2000/maps
00DA0000-00F99000 ===p 00000000 0000:0000 0 [stack (tid 11036)]
00F99000-00F9C000 rw-g 001F9000 0000:0000 0 [stack (tid 11036)]
00F9C000-00FA0000 rw-p 001FC000 0000:0000 0 [stack (tid 11036)]
01250000-01449000 ===p 00000000 0000:0000 0 [stack (tid 8144)]
01449000-0144C000 rw-g 001F9000 0000:0000 0 [stack (tid 8144)]
0144C000-01450000 rw-p 001FC000 0000:0000 0 [stack (tid 8144)]
01450000-01649000 ===p 00000000 0000:0000 0 [stack (tid 11504)]
01649000-0164C000 rw-g 001F9000 0000:0000 0 [stack (tid 11504)]
0164C000-01650000 rw-p 001FC000 0000:0000 0 [stack (tid 11504)]
01650000-01849000 ===p 00000000 0000:0000 0 [stack (tid 5984)]
01849000-0184C000 rw-g 001F9000 0000:0000 0 [stack (tid 5984)]
0184C000-01850000 rw-p 001FC000 0000:0000 0 [stack (tid 5984)]
01850000-01A49000 ===p 00000000 0000:0000 0 [stack (tid 4340)]
01A49000-01A4C000 rw-g 001F9000 0000:0000 0 [stack (tid 4340)]
01A4C000-01A50000 rw-p 001FC000 0000:0000 0 [stack (tid 4340)]
01A50000-01C49000 ===p 00000000 0000:0000 0 [stack (tid 12152)]
01C49000-01C4C000 rw-g 001F9000 0000:0000 0 [stack (tid 12152)]
01C4C000-01C50000 rw-p 001FC000 0000:0000 0 [stack (tid 12152)]
01C50000-01E49000 ===p 00000000 0000:0000 0 [stack (tid 11244)]
01E49000-01E4C000 rw-g 001F9000 0000:0000 0 [stack (tid 11244)]
01E4C000-01E50000 rw-p 001FC000 0000:0000 0 [stack (tid 11244)]
01E50000-02049000 ===p 00000000 0000:0000 0 [stack (tid 11724)]
02049000-0204C000 rw-g 001F9000 0000:0000 0 [stack (tid 11724)]
0204C000-02050000 rw-p 001FC000 0000:0000 0 [stack (tid 11724)]
02050000-02249000 ===p 00000000 0000:0000 0 [stack (tid 5180)]
02249000-0224C000 rw-g 001F9000 0000:0000 0 [stack (tid 5180)]
0224C000-02250000 rw-p 001FC000 0000:0000 0 [stack (tid 5180)]
FFA00000-FFBED000 ===p 00000000 0000:0000 0 [stack (tid 2492)]
FFBED000-FFBF0000 rw-g 001ED000 0000:0000 0 [stack (tid 2492)]
FFBF0000-FFC00000 rw-p 001F0000 0000:0000 0 [stack (tid 2492)]
FFC00000-FFDED000 ===p 00000000 0000:0000 0 [stack (tid 9128)]
FFDED000-FFDF0000 rw-g 001ED000 0000:0000 0 [stack (tid 9128)]
FFDF0000-FFE00000 rw-p 001F0000 0000:0000 0 [stack (tid 9128)]
FFE00000-FFFE3000 ===p 00000000 0000:0000 0 [stack (tid 1928)]
FFFE3000-FFFE6000 rw-g 001E3000 0000:0000 0 [stack (tid 1928)]
FFFE6000-100000000 rw-p 001E6000 0000:0000 0 [stack (tid 1928)]
--
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] 2+ messages in thread