From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12136 invoked by alias); 4 May 2016 12:42:30 -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 12106 invoked by uid 89); 4 May 2016 12:42:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:1326, H*Ad:U*libffi-discuss, rigid X-HELO: mail-lf0-f53.google.com Received: from mail-lf0-f53.google.com (HELO mail-lf0-f53.google.com) (209.85.215.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 04 May 2016 12:42:15 +0000 Received: by mail-lf0-f53.google.com with SMTP id y84so58442007lfc.0 for ; Wed, 04 May 2016 05:42:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=O4aQwj5VcSwMQibBP7MuTkxX12WewNUEQNPFNcyOIM0=; b=Hi098ESCY/KitW6KXGlo0G6+aqQ5CCJ4lLnaDQcieDTk4O76ZUPWBYkMR+Ny7lPfXW DaXv5isaWJW/RDL7IFNztmxOrgMlVBeDzW8W+uVIEtWkoyG96Z+FWIFb4EetA9f3GMHQ U44icyFuxLPKLIjQbGY8OtLHnr+vZvkcrc/6ZfxIueO28ITIl5gysjq9hV77g5Bdfh9n bh6w8uK+5Ue0GI/Q5/zwqI8dvP0OCgon3zZfEru+ZB4gUH20/pncszHnzUe+Qrk5X4NW QSArBF98EAoHD3NFiMdzt1zPMp8c9MUQ5zDk2Wa2J/kMrSiOyIE90sjRx5Gev9u3kWiV rTyw== X-Gm-Message-State: AOPr4FXMCOE/3eeClgOGAKsltWtMR9c4SlfJHcczsSqu9t1xFN1m9MeUAEDhAftXpsFo9nela+hULsjt9FSuGw== MIME-Version: 1.0 X-Received: by 10.112.162.169 with SMTP id yb9mr4036999lbb.70.1462365732096; Wed, 04 May 2016 05:42:12 -0700 (PDT) Received: by 10.25.154.196 with HTTP; Wed, 4 May 2016 05:42:12 -0700 (PDT) In-Reply-To: <5729CC44.10601@redhat.com> References: <1462310910.16919.2.camel@gmail.com> <84bfffeb-8172-85fd-6631-d2199eb21d94@redhat.com> <5729CC44.10601@redhat.com> Date: Wed, 04 May 2016 12:42:00 -0000 Message-ID: Subject: Re: Avoid stack/heap executable memory From: Anthony Green To: Andrew Haley Cc: Richard Henderson , "libffi-discuss@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016/txt/msg00020.txt.bz2 Can't there be special kernel support for this kind of situation? Like https://pax.grsecurity.net/docs/emutramp.txt (resent because original was bounced by sourceware) AG On Wed, May 4, 2016 at 6:17 AM, Andrew Haley wrote: > 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.