> -----Original Message-----
> From: Andy Polyakov via RT [mailto:[email protected]]
> Sent: Monday, March 22, 2010 22:48
> To: Kees Dekker
> Cc: [email protected]
> Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
>
> >>> I agree that OPENSSL_isservice() cannot be changed,
> >> ??? My suggestion for *you* was to modify it to unconditionally
> >> return 1...
> > Our application can both run in foreground and in service
> context. So
> > simply changing to return 1 is not possible.
>
> If changing to return 1 is not acceptable, how come conditional
> compilation freezing to some unconditional behavior is?
Changing to 1 is acceptable, but changing code is very difficult.
In our current build process, we will use the code unchanged.
That is the reason that I like that the code is part of the standard source
base of openSSL.
>
> > May be there is another
> > method to check wether a windows process is a service, without using
> > user32.dll.
>
> As mentioned one can do it with Native NT API, but it's quite special
> and belongs rather in [your] application than in openssl.
Yes and no. As soon as there is any openSSL code, using APIs from user32.dll,
my application still have a dependency to user32.dll.
Although I cannot prove, my feeling is that the silly fact that an application
loads user32.dll also results in usage of desktop heap memory.
I would like to have no reference at all to user32.dll. I will try to get some
figures in this region.
Unfortunatelly, Microsoft dheapmon supports only 'older' platforms (and not
recent SPs, e.g. XP SP3 not). As soon as I have date I will let you know.
>
> > At least for windows 2008/vista etc, you can assume that
> > a process is a service, if it is running in session 0 (e.g. see
> > WTSGetActiveConsoleSessionId(), supported from Windows 2003 onwards)
>
> You most likely mean ProcessIdToSessionId for current process.
True.
>
> > However, processes can run as non-service, but that will not
> > necessary mean that there is a visible console (e.g. another process
> > may call the process using OPENSSL_isservice(), but not redirect
> > stdout or stderr).
>
> Which reminds me. *If* you redirect stderr to a file when you
> start your
> application and never call RAND_screen (once again, openssl
> itself does
> not call it), then /delayload-ing user32.dll and gdi32.dll
> will do the
> trick. This is because OPENSSL_isservice is *not* called if stderr is
> redirected or attached to console window.
>
> > I would highly appreciate if a define can be used
> > (configurable with Configure) to tell that we want [no]
> unconditional
> > logging to the evenviewer.
>
> No. The maximum I'd go for is a way for application to
> provide a way to
> override OPENSSL_isservice. E.g. *application* can dllexport
> _OPENSSL_isservice and OPENSSL_isservice can check for its
> presence and
> in such case invoke it.
>
> > My feeling is - but I can't prove - that if applications load
> > user32.dll, some init code in user32.dll will already occupy some
> > bytes in the windows heap.
>
> Can't you run
> main(){getchar();LoadLibrary("user32.dll");getchar();} and
> *see* that with dheapmon? "feeling" should not be part of
> programmer's
> vocabulary.
Hmm :-) I did actually measure our own application, but that one is so big,
that I was not 100% sure that the usage of desktop heap memory was caused by
user32.dll.
We removed all references (except those caused by the openSSL static lib) to
user32.dll and made user32.dll delayed loaded. We saw some decrease of desktop
heap usage.
It may help too if RAND_screen() + readscreen() moved to a separate file,
preventing that user32.dll will be used if no RAND_screen was used.
The linker is not that clever if another function is being used in the same
file, to remove references to system dlls of not used functions (even if link
time optimization/LTCG is active).
I tried the code above, and saw:
Closed as many applications as possible, and then just before LoadLibrary():
Desktop Heap 3145728 (0x 300000) Bytes
Committed 856064 (0x d1000) Bytes
Uncommitted 2289664 (0x 22f000) Bytes
Allocated 407472 (0x 637b0) Bytes
Total Freed 448592 (0x 6d850) Bytes
Unused 2738256 (0x 29c850) Bytes
Used Rate ( 13.0) %
After LoadLibrary():
Desktop Heap 3145728 (0x 300000) Bytes
Committed 856064 (0x d1000) Bytes
Uncommitted 2289664 (0x 22f000) Bytes
Allocated 410696 (0x 64448) Bytes
Total Freed 445368 (0x 6cbb8) Bytes
Unused 2735032 (0x 29bbb8) Bytes
Used Rate ( 13.1) %
So simply loading user32.dll increased the amount of used memory with 3224
bytes (410696 - 407472). In our case, when 1000 users are logged on, this will
almost blow up the used heap.
>
> >>> 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.
> >> ??? I don't understand. If users don't have an option to invoke
> >> code of their choice, then /delayload-ed library will remain
> >> unmapped and it won't be a problem. But if they have such option,
> >> then how not having it linked with openssl would prevent them from
> >> mapping it and consuming session memory?
> >
> > Our application is a VM, like Java. Users can execute their own code
> > within that VM. Based on their code used, openSSL (and cURL) can be
> > used or not...
>
> Question was if they can LoadLibrary("user32.dll") or make any other
> call *of their choice* that would bring user32.dll into
> process address
> space? But it's more of a rhetorical question for me, because
> it appears
> that you don't formulate the problem correctly.
>
> > As I understand correctly (I'm not sure),
> > RAND_screen(), and effictively read_screen() is used to generate a
> > seed. Is it not possible to create a seed, without using gdi32.dll
> > and/or user32.dll?
>
> Once again, openssl *itself* doesn't call RAND_screen.
> *Application* can
> call it to possibly improve seed quality, but the decision is left to
> application.
>
> > Some comments in Randomizer.cpp
>
> What's Randomizer.cpp?
>
> > already say (which may point to some
> > disadvantages of the current READ_screen() implementation):
> >
> > * OpenSSL provides the function RAND_screen(), by G. van Oosten,
> > which hashes the contents of the screen to generate a seed. This is
> > not useful for an extension or for an application which launches at
> > startup time, since the screen is likely to look identical from one
> > launch to the next. This method is also rather slow.
>
> Correct. Which is why the decision is left to application and the
> intention was not to read screen when application is executed
> in service
> context. "Intention" refers to the fact that we've established that
> there is a bug in first "if" statement in readscreen. A.
>
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
