From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 87D221F8C6 for ; Wed, 14 Jul 2021 18:26:07 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 99D0A398800A for ; Wed, 14 Jul 2021 18:26:06 +0000 (GMT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by sourceware.org (Postfix) with ESMTPS id 19C5B3858036; Wed, 14 Jul 2021 18:25:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19C5B3858036 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=morinfr.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=morinfr.org Received: from bender.morinfr.org (unknown [82.64.86.27]) by smtp4-g21.free.fr (Postfix) with ESMTPS id 3C3C719F593; Wed, 14 Jul 2021 20:25:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=morinfr.org ; s=20170427; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xUd0MYQxSoQ3BnK3NSv2ZGPYJEnt+sZ3ea0obcYIQNs=; b=xCoqG/a2RTN574g6DEHFtSaTiG BMsXujUkFxLLqytHI3FW6tXQinY1sBD9L5zkQ0hkFUrT0S4lz2WapSA6AevyueXy+iaaz/FlAWqK6 o+qHphPYQY+CQrdGk1o0abQlqJbHwWkUXqf6a+Pf3b9uA2c5uN/JEfOl4ekG2Wp/mltA=; Received: from guillaum by bender.morinfr.org with local (Exim 4.92) (envelope-from ) id 1m3jZw-0005Ml-Ru; Wed, 14 Jul 2021 20:25:52 +0200 Date: Wed, 14 Jul 2021 20:25:52 +0200 From: Guillaume Morin To: Siddhesh Poyarekar Subject: Re: [PATCH v8 03/10] Remove __morecore and __default_morecore Message-ID: <20210714182551.GA16858@bender.morinfr.org> References: <20210713073845.504356-1-siddhesh@sourceware.org> <20210713073845.504356-4-siddhesh@sourceware.org> <9925362a-d278-a0ad-f504-ae08ca93f628@gotplt.org> <20210714125415.GA24678@bender.morinfr.org> <45ba79b4-02e6-fae5-ae9b-db6c8a01aecb@gotplt.org> <20210714164204.GA1103@bender.morinfr.org> <6364b66d-14a8-3086-00ad-a0def6995c54@gotplt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6364b66d-14a8-3086-00ad-a0def6995c54@gotplt.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fweimer@redhat.com, Siddhesh Poyarekar , Guillaume Morin , libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" 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