> -----Original Message----- > From: Kees Dekker > Sent: Tuesday, March 16, 2010 22:53 > To: '[email protected]' > Cc: [email protected] > Subject: RE: [openssl.org #2194] Unwanted dependencies to user32.dll > > > -----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. > > > > > As an addition: if running on Vista/Windows 2008 as an service (i.e. in session 0) what will happen when creating a bitmap, as done in readscreen() now? If it will always create the same bitmap, it may be less useful for generating a random number.
Regards, Kees ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
