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
