Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> On Jul 31, 2018, at 4:59 AM, Matt Caswell wrote: > > To be clear I can only think of one leak that we have at process exit > (well technically its two instances of the same thing). And that leak is > not the result of a *mistake*. It is a deliberate design decision to > workaround around a problem on some platforms (i.e. anything that isn't > Windows, Linux or Solaris, IIRC). There's at least one more, we don't call X509_PURPOSE_cleanup(), without which we leak memory allocated via X509_PURPOSE_add(). There may be other static allocations that the test suite does not exercise. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 31/07/2018 01:10, Jordan Brown wrote: On 7/30/2018 12:27 PM, Viktor Dukhovni wrote: The only time such "leaks" come into play is process exit and library unload. Process exit is not the only time that libraries get unloaded. I don't happen to remember any details, but I know we've had problems with libraries that got unloaded because they were dependencies of other shared objects that are intended to be used on a "load, call, unload" basis. And *this* is the reason why having a common library like OpenSSL or libc refuse to get unloaded on the fly is such a horrible idea. I still recall the problems when (decades ago) Borland added such anti-unload code to some of their compiler-bundled libraries. There are processes that naturally run for a lot longer than the library-format plugins inside them, and it is highly valuable to end users to be able to upgrade those plugins on the fly without restarting the long-lived container, with all the other state it holds. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 30/07/18 19:08, Marty G wrote: > On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote: > >> > I never thought I'd see the day that someone would have to defend >> not leaking memory in pivotal security code like openssl however >> >> >> >> To be accurate, it was a couple of people saying that memory leaks *on >> process exit* aren’t be a big deal. >> >> >> >> > Fair enough, but it is my understanding that some RTOSes do not > necessarily dealloc all memory alloc'd by a proc on proc exit. So why > not just have a rule "don't litter" instead of having complicated rules > of when it is "probably ok to litter"? Exploits nearly always leverage > something programmers didn't anticipate or happens in a layer they are > relying on but not directly coding so it seems fairly clear that the > best path is to reduce those unknowns by explicitly cleaning up. Taking > the time to track down a memory leak rarely results in merely fixing a > memory leak; usually another programming misstep is also found in > conjunction with the leak. Just my $0.02 > > To be clear I can only think of one leak that we have at process exit (well technically its two instances of the same thing). And that leak is not the result of a *mistake*. It is a deliberate design decision to workaround around a problem on some platforms (i.e. anything that isn't Windows, Linux or Solaris, IIRC). See: https://github.com/openssl/openssl/blob/43a0f2733a943799060ea275516fcce00d89eb38/crypto/init.c#L145-L168 https://github.com/openssl/openssl/blob/43a0f2733a943799060ea275516fcce00d89eb38/crypto/init.c#L720-L739 Any other leaks should hopefully be being caught by our mem leak testing. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 7/30/2018 11:12 AM, Michael Wojcik wrote: > As for Jordan's objection: If you don't know the source of your > "leaks", then I can't say I'm particularly impressed with a > zero-"leak" policy. That amounts to "let's burn a lot of cycles during > process termination, rather than understand what we're doing". *Fully* understanding the implications of a bug can be quite difficult. Often it is much easier to observe that there is a clear bug, fix it, and move along. Are there cases where this particular leak is a problem? Just because the developer can't think of any doesn't mean that there are none. Is it better to spend developer effort proving that a particular leak is harmless, or fixing it? And that doesn't consider the cost to the *next* developer, who runs a leak test, finds a dozen leaks, and then needs to research each one to be sure that it isn't a result of their change. -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 7/30/2018 12:27 PM, Viktor Dukhovni wrote: > The only time such "leaks" come into play is process exit and library > unload. Process exit is not the only time that libraries get unloaded. I don't happen to remember any details, but I know we've had problems with libraries that got unloaded because they were dependencies of other shared objects that are intended to be used on a "load, call, unload" basis. -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> On Jul 30, 2018, at 3:43 PM, Marty G wrote: > >> Spending valuable cycles to eliminate these is not the most productive >> use of our time. I meant "developer cycles", not CPU cycles. > How often does a process exit? Only once. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 07/30/2018 03:27 PM, Viktor Dukhovni wrote: The only time such "leaks" come into play is process exit and library unload. My advice is to not unload the library and to accept the fact that a small fixed amount of memory might not be deallocated at exit. Typically, even "valgrind" will not report "leaks" for addresses that are still referenced, so the static allocations are not a problem. Spending valuable cycles to eliminate these is not the most productive use of our time. How often does a process exit? Only once. After a process running for billions of cycles in thousands or millions of loops and whatnot I hardly think the relative few at the end for clean up could remotely be considered "valuable" relative to the total number of cycles executed in life of the process. Unless you are talking about developer's time and not the processes time. In which case I still disagree, but it is your time not mine so I won't go there. I think the forest is being missed for the trees here, but I'm going to bow out as I've said my piece -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> On Jul 30, 2018, at 3:00 PM, Marty G wrote: > > Of course I applaud the team's memleak testing! How could my post be > interpreted otherwise? I wasn't trying to single anyone out, just the > general idea that any memory leak is of little concern when the implications > of the leak aren't fully known if the cause of the leak isn't known, and if > one knows the cause, why not deal with it as simple good practice? One time initialization that allocates an object for the lifetime of the process has justifiably not been considered a "leak". Refactoring code to enable exit-time deallocation of static allocated objects is mostly fruitless work. The only time such "leaks" come into play is process exit and library unload. My advice is to not unload the library and to accept the fact that a small fixed amount of memory might not be deallocated at exit. Typically, even "valgrind" will not report "leaks" for addresses that are still referenced, so the static allocations are not a problem. Spending valuable cycles to eliminate these is not the most productive use of our time. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 07/30/2018 02:34 PM, Salz, Rich via openssl-users wrote: * So why not just have a rule "don't litter" Have you looked at, say, the memleak testing we do? Thanks for the two cents. Of course I applaud the team's memleak testing! How could my post be interpreted otherwise? I wasn't trying to single anyone out, just the general idea that any memory leak is of little concern when the implications of the leak aren't fully known if the cause of the leak isn't known, and if one knows the cause, why not deal with it as simple good practice? But nothing beats good programming habits for cleaning up, i.e. "not littering" in the first place, as after the fact testing doesn't necessarily catch all cases where leaks can occur. Analogous care at the programming stage applies to buffer overruns also as catching them after the fact is a dynamic trap shoot. Same philosophy though. As previously noted by another in this thread, the memleak may be load or data size dependent. Or it may be dependent on some intermittent state of the underlying OS. Some leaks can occur from structures accessed only via handles to the process and the OS doesn't necessarily release those structures when a process exits. But if the dev *always* explicitly makes the call to the system to release those structures via the handle then one can be far less concerned about the implications about what the system will or won't do if one doesn't For what it is worth, from my view, I'm addressing a small percentage of developers out there who may have not considered the implications of some of this and how easy it can be avoided altogether with some simple practices at code time, rather than trying to mop up later in dynamic testing. I have nothing but the highest respect and gratefulness for the sweat and care behind openssl and wouldn't be posting at all if I didn't, so thank you! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
* So why not just have a rule "don't litter" Have you looked at, say, the memleak testing we do? Thanks for the two cents. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Salz, Rich via openssl-users > Sent: Monday, July 30, 2018 11:28 > > I never thought I'd see the day that someone would have to defend not > > leaking memory > > in pivotal security code like openssl however > To be accurate, it was a couple of people saying that memory leaks *on > process exit* aren’t be a big deal. And only singleton leaks, at that. But why sweat comprehension when there's an opportunity to be rude? As for Jordan's objection: If you don't know the source of your "leaks", then I can't say I'm particularly impressed with a zero-"leak" policy. That amounts to "let's burn a lot of cycles during process termination, rather than understand what we're doing". -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote: > I never thought I'd see the day that someone would have to defend not leaking memory in pivotal security code like openssl however To be accurate, it was a couple of people saying that memory leaks *on process exit* aren’t be a big deal. Fair enough, but it is my understanding that some RTOSes do not necessarily dealloc all memory alloc'd by a proc on proc exit. So why not just have a rule "don't litter" instead of having complicated rules of when it is "probably ok to litter"? Exploits nearly always leverage something programmers didn't anticipate or happens in a layer they are relying on but not directly coding so it seems fairly clear that the best path is to reduce those unknowns by explicitly cleaning up. Taking the time to track down a memory leak rarely results in merely fixing a memory leak; usually another programming misstep is also found in conjunction with the leak. Just my $0.02 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> I never thought I'd see the day that someone would have to defend not leaking > memory in pivotal security code like openssl however To be accurate, it was a couple of people saying that memory leaks *on process exit* aren’t be a big deal. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 07/30/2018 12:52 PM, Jordan Brown wrote: Because a zero-leaks policy is a lot easier to manage than having to make a judgement call on each leak whether or not it's important, and having to filter out "unimportant" leaks when you're trying to find out whether you've introduced any "important" leaks. Maybe the test suite only caused the program to leak one buffer, but that doesn't tell you whether a real workload (or a malicious workload) will leak gigabytes. -- Jordan Brown, Oracle Solaris ^^^ this So much has changed in programming culture over the decades for me to be able to call it "engineering" any more. Too much code equivalents of duct tape, chewing gum, and kite string holding things together out there and so many consider that normal and ok. I never thought I'd see the day that someone would have to defend not leaking memory in pivotal security code like openssl however -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 7/30/2018 7:18 AM, Michael Wojcik wrote: > I don't know why people worry about singleton memory "leaks". If the > leak isn't growing over the lifetime of the process, it's not causing > any trouble. I've seen some teams obsessing about getting clean > reports from dynamic-analysis tools like Valgrind. In most > environments that's pointless "optimization" and a waste of > development resources. Because a zero-leaks policy is a lot easier to manage than having to make a judgement call on each leak whether or not it's important, and having to filter out "unimportant" leaks when you're trying to find out whether you've introduced any "important" leaks. Maybe the test suite only caused the program to leak one buffer, but that doesn't tell you whether a real workload (or a malicious workload) will leak gigabytes. -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Monday, July 30, 2018 08:02 > > My recommendation is never unload a library once loaded. I agree, at least in most cases. I don't know why people worry about singleton memory "leaks". If the leak isn't growing over the lifetime of the process, it's not causing any trouble. I've seen some teams obsessing about getting clean reports from dynamic-analysis tools like Valgrind. In most environments that's pointless "optimization" and a waste of development resources. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> On Jul 30, 2018, at 8:26 AM, Graham Leggett wrote: > > Should they suppress attempts to unload mod_ssl, apr_crypto_openssl, libpq, > libldap, etc if we know for sure that openssl < 1.1.0 is linked to them? My recommendation is never unload a library once loaded. I don't see the point, unloading and reloading on demand risks crashes and memory leaks. Others may disagree, but I prefer to not assume that unloading is safe. In OpenSSL 1.1.0, we try to do our best to make it safe, but some one-time static allocations will still leak and crash safety is likely platform-specific. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 24 Jul 2018, at 18:06, Viktor Dukhovni wrote: >> Or is it correct in v1.1.0 and above to just not initialise anything at all, >> not clean anything up at all, and expect openssl to “do the right thing” >> when mod_ssl is unloaded? > > Yes. And *especially* when the code that depends on OpenSSL is itself a > library. > OpenSSL is now (and should ideally always have been) self-initializing. What should be behaviour be in openssl < 1.1.0? The scenario is as follows: - httpd runs. - httpd dynamically loads mod_ssl, apr_crypto_openssl, libpq, libldap, etc. - mod_ssl, apr_crypto_openssl, libpq, libldap, etc in turn dynamically load openssl. - At some point a graceful shutdown is attempted and mod_ssl, apr_crypto_openssl, libpq, libldap, etc are unloaded. - …what next? How should mod_ssl, apr_crypto_openssl, libpq, libldap, etc handle the unloading of openssl < 1.1.0? Should they run the openssl init functions but not the teardown functions? (And just accept a leak). Should they suppress attempts to unload mod_ssl, apr_crypto_openssl, libpq, libldap, etc if we know for sure that openssl < 1.1.0 is linked to them? Regards, Graham — -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
> On Jul 24, 2018, at 7:40 AM, Graham Leggett wrote: > > Or is it correct in v1.1.0 and above to just not initialise anything at all, > not clean anything up at all, and expect openssl to “do the right thing” when > mod_ssl is unloaded? Yes. And *especially* when the code that depends on OpenSSL is itself a library. OpenSSL is now (and should ideally always have been) self-initializing. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?
On 24 Jul 2018, at 12:15, Graham Leggett wrote: > Over at httpd we’re struggling with crashes and instability caused by > attempts by various independent libraries we link to, all of which in turn > link to openssl, initialising openssl multiple times. In turn these separate > libraries might de-initialise openssl on shutdown expecting a re-initiailise > to work and hilarity ensues. > > What is the correct way to handle openssl initialisation when multiple > independent libraries are all trying to initialise openssl independently of > one another? > > Is there reference counting of some kind? > > Could instability be caused by not matching the correct teardown function > calls with the correct setup function calls? Focusing a little closer on openssl v1.1.0 we get the following, but this also seems broken at first glance. https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html "Once OPENSSL_cleanup() has been called the library cannot be reinitialised”. In our case, httpd will load mod_ssl (and in APR apr_crypto_openssl) which is in turn linked to openssl, and during a restart the module (and therefore the link to openssl I believe) will be unloaded, and thus OPENSSL_cleanup() will fail when httpd finally exits and calls atexit. Am I interpreting the above correctly? Or is it correct in v1.1.0 and above to just not initialise anything at all, not clean anything up at all, and expect openssl to “do the right thing” when mod_ssl is unloaded? Regards, Graham — -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
