[openssl-users] Changing malloc/debug stuff

[Salz, Rich]

I want to change the memory alloc/debug things.

 

Right now there are several undocumented functions to allow you to swap-out the malloc/realloc/free routines, wrappers that call those routines, debug versions of those wrappers, and functions to set the set-options versions of those functions.  Yes, really J  Is anyone using that stuff?

 

I want to change the model so that there are three wrappers around malloc/realloc/free, and that the only thing you can do is change that wrapper.  This is vastly simpler and easier to understand.  I also documented it.  A version can be found at https://github.com/openssl/openssl/pull/450

 

I’ve posted about this before.  But I’m asking again if this kind of change will cause problems for anyone.

 

Thanks.

 

-- 

Senior Architect, Akamai Technologies

IM: rich...@jabber.at Twitter: RichSalz

 

[Jakob Bohm]

On 17/12/2015 10:28, Salz, Rich wrote:
>
> I want to change the memory alloc/debug things.
>
> Right now there are several undocumented functions to allow you to
> swap-out the malloc/realloc/free routines, wrappers that call those
> routines, debug versions of those wrappers, and functions to set the
> set-options versions of those functions. Yes, really J Is anyone
> using that stuff?
>
> I want to change the model so that there are three wrappers around
> malloc/realloc/free, and that the only thing you can do is change that
> wrapper. This is vastly simpler and easier to understand. I also
> documented it. A version can be found at
> https://github.com/openssl/openssl/pull/450
>
> I’ve posted about this before. But I’m asking again if this kind of
> change will cause problems for anyone.
>

I don't need it so I don't object. But if anyone objects,
you could write a compatibility module that can be called
to use the new interface to change in a compatible variant
of the old wrappers, which would then provide the old
hooks/facilities when needed while staying out of the way
(not even being linked into static programs) for the rest
of us.

I guess this is because that interface is not a part of a
commercial grade full featured SSL/TLS and general purpose
crypto library, it is just a means to do quality assurance
on said library.


Enjoy and Merry Christmas

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

[Salz, Rich]

> I don't need it so I don't object. But if anyone objects, you could write a ...

Good point!

> I guess this is because that interface is not a part of a commercial grade full
> featured SSL/TLS and general purpose crypto library, it is just a means to do
> quality assurance on said library.

That seems to be the main usage, yes. I think it had more uses in the early days such as on old windows/msdos?

> Enjoy and Merry Christmas

And a happy new year. Or bah, humbug :)

/r$

[Jakob Bohm]

On 17/12/2015 19:03, Salz, Rich wrote:

I don't need it so I don't object.  But if anyone objects, you could write a ...

Good point!

I guess this is because that interface is not a part of a commercial grade full
featured SSL/TLS and general purpose crypto library, it is just a means to do
quality assurance on said library.

That seems to be the main usage, yes.  I think it had more uses in the early days such as on old windows/msdos?

Old Windows/msdos was the most widespread platform where
the compiler provided malloc/free tended to be crap and
had to be overridden in a compiler specific way to make
it work reasonably.  Note that this was a *compiler*
specific issue and tended to depend on both the brand,
version and sometimes even command line options of the
compiler.

However even for Win16, MS-DOS and OS/2 16-bit, the
ability to redirect all memory calls through a user
provided set of malloc/free/realloc/msize functions
would do the job.  The hard part was writing those
override functions, even with a your copies of TAOCP
and K&R (2nd ed) handy.

A completely different use for special memory
allocation work would be to take advantage of
algorithm specific knowledge to optimize allocation
and system call patterns, such as keeping all the
small allocations for a decoded X.509 certificate or
all the intermediaries for an RSA calculation
together.

[Salz, Rich]

> > https://github.com/openssl/openssl/pull/450
>
> This seems much more sane.

I'll settle for less insane :)

[Nico Williams]

On Thu, Dec 17, 2015 at 08:16:50PM +0000, Salz, Rich wrote:
> > > https://github.com/openssl/openssl/pull/450
> >
> > This seems much more sane.
>
> I'll settle for less insane :)

That is, I think, the best you can do. Some allocations might have
taken place by the time a wrapper or alternative allocator is
installed, in which case something bad will happen. In the case of
alternative allocators the something bad is "it blows up", while in the
case of a wrapper the something bad is "some state/whatever will be
off".

A fully sane approach would be to have every allocated object internally
point to its destructor, and then always destroy by calling that
destructor instead of a global one. (Or call a global one that knows
how to find the object's private destructor pointer, and then calls
that.) If you wish, something more OO-ish. But for many allocations
that's not possible because they aren't "objects" in the sense that
matters. You could always wrap allocations so that they always have
room at the front for the corresponding destructor, then return the
offset of the end of that pointer, but this will be very heavy-duty for
many allocations. So, all in all, I like and prefer your approach.

Nico
--

[Nico Williams]

On Thu, Dec 17, 2015 at 09:28:28AM +0000, Salz, Rich wrote:
> I want to change the memory alloc/debug things.
>
> Right now there are several undocumented functions to allow you to
> swap-out the malloc/realloc/free routines, wrappers that call those
> routines, debug versions of those wrappers, and functions to set the

> set-options versions of those functions. Yes, really :) Is anyone
> using that stuff?

This is another one of those things that isn't easy to deal with sanely
the way OpenSSL is actually used (i.e., by other libraries as well as by
apps).

> I want to change the model so that there are three wrappers around
> malloc/realloc/free, and that the only thing you can do is change that
> wrapper. This is vastly simpler and easier to understand. I also
> documented it. A version can be found at

> https://github.com/openssl/openssl/pull/450

This seems much more sane.