> -----Original Message----- > From: Andy Polyakov via RT [mailto:[email protected]] > Sent: Tuesday, March 16, 2010 22:23 > To: Kees Dekker > Cc: [email protected] > Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll > > > When building openSSL on Windows with: > > > > * CONFIG=VC-WIN64A or CONFIG=VC-WIN32 > > * no-shared no-threads -DWINVER==0x0501 > -D_CRT_NON_CONFORMING_SWPRINTFS > > * With Visual Studio 2005 > > > > I get dependencies to user32.dll, when using libeay32.lib, e.g: > > > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__delet...@4 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__deleteobj...@4 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__getbitmapb...@12 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__bit...@36 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__getobje...@12 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__selectobj...@8 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__createcompatiblebit...@12 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__getdevicec...@8 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__createcompatibl...@4 > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved > external symbol __imp__create...@16 > > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved > external symbol __imp__getuserobjectinformati...@20 > > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved > external symbol __imp__getprocesswindowstat...@0 > > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved > external symbol __imp__getdesktopwin...@0 > > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved > external symbol __imp__messageb...@16 > > > > These dependencies are unwanted for our application, since using > > user32.dll will result in Windows desktop exhaustion if too > many users > > are logged in to a Windows system (via a service) and use > our application. > > I would like to have an option to prevent any interaction to UI > > (user32.dll) related code. Can you please add such option? > > > > As far as I could see, the code in rand_win.c/cryptlib.c > are related to: > > - OPENSSL_isservice(), which uses GetDesktopWindow(), > > GetProcessWindowStation(), GetUserObjectInformationW() > > - and a number of functions in rand_win.c e.g. readscreen() > > - readscreen() seems to be used only in RAND_SCREEN() and has some > > comments that the function exists only for backward > compatibility. If > > this compatibility can be turned off, much of the dependencies to > > user32.dll are removed then. > > > > I don't know how to fix this. But I would like to share > some thoughts: > > > > * Windows 2008/Vista does not allow to call MessageBox() if the > > calling process is a service (and running in session 0). So > > MessageBox() is only useful if a normal user, connected to an > > interactive Windows Desktop, will call openssl executables. > > This is misconception. It's not like 2008/Vista does not > allow to call > MessageBox in service, it's just that you don't see nor can > you interact
You are right. However, an invisible message box is not very useful for end-users. I agree that OPENSSL_isservice() cannot be changed, but you can decide to log an event always. So all if (OPENSSL_isservice()) can be removed. Or change it to a define for configure: OPENSSL_DO_EVENTLOG_REPORTING? The if (!OPENSSL_isservice()) prevents to do more things with user32.dll, and delayload will help in this region. I'm not sure whether I understand the code in readscreen() correctly, but if the code is used for generating a random number, I would prefer not use functions from user32.dll but some other approach... (if that is possible) > with it. Secondly [and more importantly!] openssl won't call > MessageBox > if it finds itself running in Windows service context. > Instead it will > log the message to event log. > > > * I saw a lot of NT4 code. > > What NT4 code? You must be referring to _WIN32_WINNT macro > sometimes set > to 0x400. It does not denote NT4-specific code, it denotes > that NT4 is > required *minimum*. Meaning that it targets *all* Windows versions > *past* 4: 2000, XP, 2003, Vista, 2008, 7, etc. Example: rand_win.c, check on osverinfo.dwMajorVersion < 5 (i.e. NT4). And all places, using GetVersion() >= 0x80000000 points to Win9x code. But, please ignore this remark. My key point is the dependency to user32.dll. Sorry for causing confusion. > > > * Background information on desktop exhaustion: > > > http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-h eap-overview.aspx > > > <http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop- > heap-overview.aspx> > > and > > > http://blogs.technet.com/markrussinovich/archive/2010/02/24/33 > 15174.aspx > > > <http://blogs.technet.com/markrussinovich/archive/2010/02/24/3 > 315174.aspx> > > As already implied, when executed in Windows service context, > openssl is > programmed to abstain from making user32 and gdi32 calls and won't > interact with UI. But user32.dll is mapped and this does mean > that some > session memory is consumed, *but* *not* beyond absolute > minimum implied > by mere initialization of user32.dll. The only situation I > can think of > when resource exhaustion could be a problem is when a > separate *process* > is created for every user/connection. Is it your case? If > not, then it > shouldn't even be a concern. If yes, i.e. a separate *process* is > created for every user/connection, then I'd suggest to modify > OPENSSL_isservice() to immediately return 1(**) and > /delayload:gdi32.dll > /delayload:user32.dll and keep it is as private customization. A. Yes, we do start a new process for every user/connection. I can of course add /delayload:user32.dll, but the risc is that users will too easy use code from user32.dll. It would be very useful if all references to user32.dll have been removed. Just as example: with default settings of some (especially x64 Windows versions), only 80 users can login using our application. The design of Windows desktop heaps in combination with the lack of tools to get more insight in heap memory usage, I would like to prevent user32.dll as much as possible. We are also seeing (on Windows versions where dheapmon still works) memory leaks. I'm not sure whether this is related to user32.dll, but the cause may be in this DLL. > > (*) For reference, most of Microsoft services have user32.dll mapped > into their address spaces, meaning that they also consume at > least some > bare minimum. > > (**) Alternative to returning 1 could be enumerating handles, > identifying windowstation one, pulling and finally checking > its name in > same manner it's currently done in OPENSSL_isservice, but > with native NT > API. Naturally also with /delayload. > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
