X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 1 Mar 2012 10:53:59 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: BLODA detection code in latest snapshot Message-ID: <20120301095359.GB2257@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20120227122614 DOT GB31025 AT calimero DOT vinschen DOT de> <4F4E3B6C DOT 1080607 AT cs DOT utoronto DOT ca> <20120229150110 DOT GA20306 AT calimero DOT vinschen DOT de> <4F4E4D03 DOT 9000305 AT cs DOT utoronto DOT ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F4E4D03.9000305@cs.utoronto.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Feb 29 11:06, Ryan Johnson wrote: > On 29/02/2012 10:01 AM, Corinna Vinschen wrote: > >On Feb 29 09:51, Ryan Johnson wrote: > >>On 27/02/2012 7:26 AM, Corinna Vinschen wrote: > >>>Hi folks, > >>> > >>> > >>>I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC". It > >>>contains two code snippets which are supposed to help diagnosing BLODA > >>>problems. > >>> > >>>If you set the environment variable CYGWIN to "detect_bloda" and then > >>>start a Cygwin process (bash or so), then Cygwin will detect two types > >>>of anomalies: > >>>[...] > >>Would it be a good idea to update the FAQ's bloda entry with this > >>info? Sure, it's probably going to give occasional false positives > >>and/or negatives, but it would definitely catch the obvious cases > >>and give a quick test for claims of bloda-free systems. You'd almost > >>want a new cygcheck -b option that could fork off a process or two > >>with detect_bloda active and capture any output that results. > >Of course I will document this at one point. So far I just didn't. > >I doubt that the cygcheck -b would be useful, though. Just call > > > > $ export CYGWIN=detect_bloda some_executable > > > >and you get what you want. > Sure. That's what I'd do also, but we're both familiar with the > bloda. I was thinking more of users sending problem reports. Telling > them to attach the output of `cygcheck -svrb' would give us useful > information even if they don't (yet) know what the bloda is let > alone whether they're affected by it. Sort of like how we could ask cygcheck already starts the `id' command. We could start it with the CYGWIN=detect_bloda setting. But I don't think that's feasible. The problem is, what application would you like to start, and what would you like to do to trigger BLODA messages? when I implemented this I didn't implement the DLL filter list at first. I ran my first tests on W7. I have one machine on which I have the installer for a known BLODA, the Bytemobile stuff, but otherwise my machines are rather stock OS + Cygwin. So it came as a surprise to me when the following happened: I started bash with CYGWIN=detect_bloda, typed `ls' to see if it works and then shifted my attention to something else. After about 30 seconds, I got the follwoing message in bash, three times in a row: Potential BLODA detected! Thread function "called outside of Cygwin DLL: C:\Windows\System32\ntdll.dll I observed this more closely and it turned out that for each foreground process which lived longer than about 30 seconds a thread function in ntdll.dll was started three times in parallel. After pretty much exactly 1 minute, all three threads disappeared again. What I'm trying to say with this example is, you just don't know what a potential BLODA will do. You don't know when it will intrude, nor do you know what you have to do so that it intrudes. Maybe it only occurs when you press a key or open a socket connection, or only if you move your mouse out of the Window, or if you perform a rain dance. I don't think you have the faintest chance to catch BLODAs automatically, other than by enhancing the BLODA tests for known BLODAs in cygcheck. That's what would be most helpful in the long run. The BLODA test in Cygwin is just a last straw sort of thing. At least in its current implementation. > Heck, if we really wanted to go whole-hog, we could add an option to > check for dlls in $PATH that have base collisions. Once cygcheck > supported both those checks, the fork failure error message could > even tell users to run cygcheck before reporting a problem. To find base collisions it would be most helpful to run rebase with the -i option. We could add code to cygcheck to call rebase -i. > Actually, now that I think about it, we could just make cygwin list > any base collisions among dlls used by a failed forkee and point to > the FAQ entry on rebaseall. The info is at our fingertips > (dll::preferred_base) and in the absence of base collisions we could > spawn a process to check for bloda, whose output (if non-empty) is ^^^^^^^^^^^^^^^ Oh no, please don't. The Cygwin DLL should not start applcations by itself. That sounds like a potential security hole. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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