X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:subject:reply-to:to:references:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=bZm96dnp0pLPjJJ7
	V9IzWw7hvu1q5K36BrWYZqWaWyQT4XKu0o0Q4h8UdVhXw6PKfckVNJW1tJc1pcwh
	7Gd3De3QicigSebkcbERto/uRnFE0xCRy44W793HlkxVhMWWf0DoL6YZG7ZAjeyr
	Tv5dYVkeiYlWD7yuqAjfuUs3t+M=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:subject:reply-to:to:references:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=RBrTeIDhRlatHcPWjq6LDH
	P6FXE=; b=BxTtyCunuMMR1k054mpGC68fL9XJLFGw7Dg6xCULmv3gWSC18uyv0F
	J9oxmikGXqDcNAAGw0FFUOPGgMdII/y/y443ycYHJHg1K2RofVoh9XXAx5+j36Uh
	5xjBDkbw/Gly1j6pBQGLm3ycfYGm8I4faA3g8yPyJMGSR9zQk6Pdc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-4.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,UNSUBSCRIBE_BODY autolearn=ham version=3.3.2 spammy=8144, calgary, alberta, Alberta
X-HELO:	smtp-out-no.shaw.ca
X-Authority-Analysis:	v=2.2 cv=HahkdmM8 c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=N659UExz7-8A:10 a=w_pzkKWiAAAA:8 a=CCpqsmhAAAAA:8 a=IKWCxeED7lBO1y93aT4A:9 a=rKb-Vp3XXwsge9Iy:21 a=sjFNtc2INZ8rpNc3:21 a=pILNOxqGKmIA:10 a=Loncm-k6u6IA:10 a=FwDfIg3wHjcA:10 a=sRI3_1zDfAgwuvI8zelB:22 a=ul9cdbp4aOFLsgKbc677:22
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Subject:	Re: Potential BLODA issue with commercial file encryption tool
Reply-To:	Brian DOT Inglis AT SystematicSw DOT ab DOT ca
To:	cygwin AT cygwin DOT com
References:	<2FB3956C6AA03047B0818081B72B1CAF04894E27 AT KIKA1 DOT simons-voss DOT local>
Message-ID:	<7359cd3b-ed04-c3a1-1a20-030a1e3bd39e@SystematicSw.ab.ca>
Date:	Wed, 8 Nov 2017 11:24:20 -0700
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version:	1.0
In-Reply-To:	<2FB3956C6AA03047B0818081B72B1CAF04894E27@KIKA1.simons-voss.local>
X-CMAE-Envelope:	MS4wfLRFlhI7dAjg/4XYLySPbu2gmBsIDOhj/lCvkz8HsNqmMk03WJ9Z5spCOQqiM4naDfw54H4/i93TFsZulFCX2Mm9eMuYnyCOMpOYotb9DmhonlzM2/2O pNywlGrD1Hk9cwZ9SLUKRL1bp/vgJf/JjN9HzoC4SPaFwGe0JdICkQ70U8wsquweX692kA89xTH7hQ==
X-IsSubscribed:	yes

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

- Raw text -