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


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

Re: BLODA detection code in latest snapshot


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

And additionally you'll see this:

     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: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]