From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41548 invoked by alias); 4 May 2016 10:17:46 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 41538 invoked by uid 89); 4 May 2016 10:17:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=rigid, attack, Hx-languages-length:1049, HTo:U*libffi-discuss X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 04 May 2016 10:17:43 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9386E7F093 for ; Wed, 4 May 2016 10:17:42 +0000 (UTC) Received: from zebedee.pink ([10.3.113.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u44AHf7F027235; Wed, 4 May 2016 06:17:41 -0400 Subject: Re: Avoid stack/heap executable memory To: Richard Henderson , libffi-discuss@sourceware.org References: <1462310910.16919.2.camel@gmail.com> <84bfffeb-8172-85fd-6631-d2199eb21d94@redhat.com> From: Andrew Haley Message-ID: <5729CC44.10601@redhat.com> Date: Wed, 04 May 2016 10:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <84bfffeb-8172-85fd-6631-d2199eb21d94@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016/txt/msg00019.txt.bz2 On 05/04/2016 12:32 AM, Richard Henderson wrote: > Of course, this will change the ABI, but I think we can work around that (at > least for ELF with symbol versioning), and also preserve the API. Of course, > there's a *lot* that can be cleaned up if we're willing to change the API... For a long while now I've wanted to go in the opposite direction: to use a small JIT compiler to generate efficient code for invocations in both directions. It doesn't have to be very complicated, and once you've generated code for any particular set of arguments that shim can be cached for use by any function with the same argument types. This could either use an existing JIT library or a custom JIT created just for libffi. It would often be way more efficient than what we do at present. But it would keep bumping up against the "no executable and writable memory!" meme. Of course security is important, but I can't help thinking that by being rigid about this we're performing a DOS attack on ourselves. Andrew.