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

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

# 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: Wed, 29 Feb 2012 09:51:24 -0500
• Subject: Re: BLODA detection code in latest snapshot
• References: <20120227122614.GB31025@calimero.vinschen.de>

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:

- Threads injected into the process from an unknown source.

   Every thread started in a process triggers a message to the DLLs
in a process.  When the Cygwin DLL gets this message, it tweaks
the function pointer of the thread entry point so that it points to
a Cygwin function.  Usually Cygwin just performs some setup and
then starts the original thread function.

   If CYGWIN=detect_bloda, then the original function address is
evaluated and if the address is neither in the Cygwin DLL, nor in
the application image, nor in one of a few filtered system DLLs,
then Cygwin prints a message like this:

     Potential BLODA detected!  Thread function called outside of Cygwin DLL:
C:\foo\bar\baz.dll

   Of course this is not foolproof.  The only filtered system DLLs so
far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
playing around with this, and if you find that a core system DLL is
reported (like, say, advapi32.dll), then please notify this list, too.

- Some BLODAs affect the network.  Winsock allows so-called "Layered
Service Providers" (LSP).  The socket handle returned by a socket(2)
call is not a real socket, but a pseudo handle returned by the LSP.
While Cygwin tries to workaround this, it's nevertheless interesting
to learn that an LSP is installed.

   For instance, there's the "Bytemobile optimization client" on our
BLODA list at http://cygwin.com/faq/faq.using.html#faq.using.bloda
If this is installed on your machine, and if you have CYGWIN=detect_bloda
set, it's existence will be recognized twice when you try to open a
socket connection.  First it injects a thread into the application, so
you'll see something like this:

     Potential BLODA detected!  Thread function called outside of Cygwin DLL:
C:\Windows\System32\bmnet.dll

     Potential BLODA detected!  Layered Socket Service Provider:
BMA over MSAFD Tcpip [TCP/IP]

Please note that this new CYGWIN=detect_bloda setting is just for
diagnosing BLODA problems.  It's no swiss army knife to fix the BLODA
problems, but it might help to detect the cause for some of them.

Of course I'd be interested in your experience with this and in any
BLODA message you get by setting CYGWIN=detect_bloda.

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.

Ryan

--
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

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