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 AD6F81F8C6 for ; Wed, 14 Jul 2021 18:37:35 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F3D19398A48F for ; Wed, 14 Jul 2021 18:37:33 +0000 (GMT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by sourceware.org (Postfix) with ESMTPS id 3F5C439874FD; Wed, 14 Jul 2021 18:37:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F5C439874FD 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 0EF9A19F574; Wed, 14 Jul 2021 20:37:09 +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=AdzeQ7PWBqXX/JG/sw7dscYcoqykIgXkM21MUti0YMk=; b=U6UetI6hKBDzzdq+h5d+Y48s5F sK/dslq6entFD7H6qQpFZ1zVY7dDjkRdPGBWJ1wpcrGCayjaLIQzkecGfzV5ivX9Zh20DPI6E04yH 4lPMnUajfP2r58TpHsgWy94hTVZDaIRBqfd88MW/Su/Qrqxjw3eaG6INT6XkoXGvDvMY=; Received: from guillaum by bender.morinfr.org with local (Exim 4.92) (envelope-from ) id 1m3jkq-0005WW-P4; Wed, 14 Jul 2021 20:37:08 +0200 Date: Wed, 14 Jul 2021 20:37:08 +0200 From: Guillaume Morin To: Adhemerval Zanella Subject: Re: [PATCH v8 03/10] Remove __morecore and __default_morecore Message-ID: <20210714183708.GC16858@bender.morinfr.org> Mail-Followup-To: Adhemerval Zanella , Carlos O'Donell , Guillaume Morin , Siddhesh Poyarekar , fweimer@redhat.com, Siddhesh Poyarekar , libc-alpha@sourceware.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> <63c84757-92b6-703f-b017-126518bf008b@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63c84757-92b6-703f-b017-126518bf008b@linaro.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, libc-alpha@sourceware.org, Siddhesh Poyarekar , Guillaume Morin Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 14 Jul 14:42, Adhemerval Zanella wrote: > I agree with Carlos and Siddhesh rationale that a dangling function > pointer in an essential code as malloc is a security liability and it > is about time to get removed (as there is PoC out there that does it to > exploit glibc malloc). To reiterate, I have not argued to keep the hook as is. I do understand the valid concerns about potential exploitation with the current scheme. > However I think we can work towards a solution to enable within glibc > instead of pushing the support on libhugetlfs, which does *not* aim to > be a malloc replacement but rather a way to explicit provide and > manage large pages. > There is some discussion last year about providing large pages support > directly on glibc without resorting to THP [1]. The idea is to hook > up the mmap/madvise with the required flags, which seems similar of > what is required by libhugetls morecore() implementation [2]. So I think > it should be feasible to add support for the required bits on glibc > and provide a tunable to actually use it. That would be ideal. > Guillaume, would this be suffice for your use cases. The libhugetlsfs > projects does provide more functionality than glibc scope, for instance > a linker script to for bss/data and exe section to large parges, so I > glibc support would be a complement to what libhugetls provides. Yes, it would be perfect for my use case. Guillaume. -- Guillaume Morin