Re: [PATCH v8 03/10] Remove __morecore and __default_morecore

[Guillaume Morin <guillaume@morinfr.org>]

On 14 Jul 23:02, Siddhesh Poyarekar wrote:
> But that means it won't be useless in RHEL8 or current stable Debian/Ubuntu,
> so there's still time for libhugetlbfs to adapt to the change.

As I said though, there is no other way besides forking glibc's malloc.
the morecore.c implementation in libhugetlbfs is like 100 lines of code.
We're not talking apples to apples. Far from it.

> As is evident, I personally haven't followed libhugetlbfs development and
> have been carrying forward work to remove __morecore that started at least a
> year ago, if not more.  That said though, the deprecation warning
> (especially the fact that the release notes specifically mentioned malloc
> interpositioning as the alternative) ought to have made it clear that we
> weren't thinking of an alternative.

Well, I will certainly grant that someone should have reached out
sooner, though I would probably have done it if my bug report had not
been ignore for 5 years ;-)

> > Well, I do not see why morecore() does not make sense as a plugin. I am
> > not seeing any technical argument supporting that it will prevent
> > clamping down the implementation provided you document the currently
> > acceptable semantics for this interface.
> 
> Right now the debug DSO that this patch pulls out only supports the
> debugging features (malloc_check, mcheck, mtrace, old hooks) and they're not
> intended to be linked against, only used as compatibility for existing
> programs.  If __morecore is to move there, we'd have to allow linking with
> the debug DSO, which we don't want to do because it multiplies the
> interfaces we need to support.  We'd basically have two malloc interfaces to
> support then.

I did not mean to say it should be moved to the debug DSO.

What I am saying is having explicit glibc support so I can LD_PRELOAD  a
version of libhugetlbfs that would export a __morecore() that will then be
used by glibc. No function pointers that needs explicitly set.

I am suggesting morecore interposition instead of the malloc
interposition you initially suggested. That should make no security
difference at all. It just requires to agree on some semantics though
for the interface which are basically these are sbrk.

> The direction we want to take is to not have to support all this in the
> interest of simplifying the implementation and make it easier to reason,
> audit and debug.

I think I have made decent technical points that it's not complicated at
all. There are no complications or security implications that I see,
just agreeing on the semantics on one function ...
I keep hearing theoretical concerns but nobody seems to want to detail:
why morecore interposition is complicated or insecure. I'll grant you
guys are the experts here, so please humor me, I am all ears.

> The hooks fall somewhere between the last two because in the
> general case they're quite hard to reason and in the simplest case, they're
> unprotected indirections that have historically been used as vulnerability
> primitives for years.

I have not argued for you to keep the hooks as is because i understand
your concerns. I am trying to find a solution that alleviates your
understandable concerns without breaking every single libhugetlbfs
user.

Guillaume.

-- 
Guillaume Morin <guillaume@morinfr.org>