From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by sourceware.org (Postfix) with ESMTP id C759D384B0C0 for ; Thu, 28 Jan 2021 17:01:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C759D384B0C0 Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id 0089820B7192; Thu, 28 Jan 2021 09:01:29 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0089820B7192 Subject: Re: [RFC PATCH v3 0/5] Libffi Static Trampolines To: Anthony Green Cc: libffi-discuss , fweimer@redhat.com, DJ Delorie References: <20210115184653.124913-1-madvenka@linux.microsoft.com> <849643ba-5c3e-31e6-b784-d0fc2345ce00@linux.microsoft.com> <811113c4-7bda-ee21-cdb9-4ab20d1fd291@linux.microsoft.com> From: "Madhavan T. Venkataraman" Message-ID: Date: Thu, 28 Jan 2021 11:01:29 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-20.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, ENV_AND_HDR_SPF_MATCH, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 17:01:32 -0000 On 1/28/21 8:21 AM, Anthony Green wrote: > On Wed, Jan 27, 2021 at 2:45 PM Madhavan T. Venkataraman > wrote: > > On 1/27/21 12:00 PM, Anthony Green wrote: > > Thanks, Madhaven.   I think I understand now.   Are these statements true?: > > > > (a) These patches implement trampoline tables, similar to what is implemented in the iOS port.  This hardens the library by eliminating the requirement for writable executable memory. > > (b) These patches expose a new public API for hardened trampolines.  (a) uses (b), but doesn't require that (b) be public. > > (c) We can release libffi with (a) and not (b). > > > > Is this correct?   > > > > Yes. This is correct. The public API part is not required. > > > In this case, my ask is that you split this into two patches.  The first one, (a), I would like to merge as soon as it seems ready.   > OK. I will remove the public API part, sync with the latest libffi and submit a PR. > The second one I'm not so sure about yet.  Is it a solution in search of a problem? The problem currently exists in a lot of applications. However, I have not been able to find a good example in open source. It is all closed source. > Is libffi the right place for it?   Should it live in libffi, or be broken out into something that libstatictramp -- that perhaps lives in the libffi repo but doesn't pollute the libffi API?  I don't know yet, but opinions welcome. I like the idea of a libtramp living in the same repo publishing its own API. First, let us just focus on (a). Once that has been merged, I will work on the static trampoline library. I have never done library work before. So, I will need guidance on library creation, configuration, how to expose an API, how to version it, etc. I will pester you at that time with my questions. We will cross the bridge when we come to it. > > Also, please use the github PR process for the next round so we can get some automated CI going.  And I prefer reviewing patches within the github UI, tbh. > OK. Will do. > And again -- I appreciate your effort here.  This is something I've wanted more broadly in libffi ever since Landon Fuller implemented something similar in the iOS port. Thanks! Madhavan