This is the mail archive of the
mailing list for the Cygwin project.
Re: BLODA detection code in latest snapshot
- From: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- To: cygwin at cygwin dot com
- Date: Thu, 01 Mar 2012 08:19:17 -0500
- Subject: Re: BLODA detection code in latest snapshot
- References: <20120227122614.GB31025@calimero.vinschen.de> <4F4E3B6C.firstname.lastname@example.org> <20120229150110.GA20306@calimero.vinschen.de> <4F4E4D03.email@example.com> <20120301095359.GB2257@calimero.vinschen.de>
On 01/03/2012 4:53 AM, Corinna Vinschen wrote:
On Feb 29 11:06, Ryan Johnson wrote:
Point taken. The idea did sound a little too good to be true...
On 29/02/2012 10:01 AM, Corinna Vinschen wrote:
[bloda horror stories]
On Feb 29 09:51, Ryan Johnson wrote:
On 27/02/2012 7:26 AM, Corinna Vinschen wrote:
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
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
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
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.
That could be helpful.
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.
Fair enough. Security hole or not, it sounds like it wouldn't have
actually helped, so it really shouldn't be considered further.
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.
I still think reporting specific base collisions during a fork failure
-- or at least detecting their existence and telling the user to rebase
-- would be helpful. Judging from the messages that regularly hit the
list, the extra info currently delivered with fork failure messages
isn't really actionable by the average user. Plus, we could list the
offending paths (which may not all be on rebaseall's default path list)
Anyway, these were all just a bunch of musings, no big deal if they're
full of holes.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple