From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81293 invoked by alias); 4 May 2016 16:14:31 -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 81231 invoked by uid 89); 4 May 2016 16:14:31 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=jay, Jay, H*x:iPhone, H*UA:iPhone X-HELO: mail-pa0-f48.google.com Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com) (209.85.220.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 04 May 2016 16:14:15 +0000 Received: by mail-pa0-f48.google.com with SMTP id iv1so25665003pac.2 for ; Wed, 04 May 2016 09:14:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:subject:date:to; bh=T/O2xl7vK2X+MGyZXAUx808J8yazlbna0bpZyKpwNxM=; b=agO0nq93aASThif+edymvD2B9ONNTi78dcs7Qh4Fkg7itN0Lwvy/9uhYz8FUvDaIaD lyUPomM9PiZ04qg8kpn/KXJvsOpPk9Ld4IWRRUxlH8GyUVjIHhKangy+9INTC+p5z3Nw DNDMEdmB43G2yDfA8+cO4fV970eteGhGrKv6R7u03katpOFKvm8cGwWva0KPRbtP0rii uw19StOitl4U0pxooPF5dGMNunvrXtW7FMeoq0p6KZBaxiDs8K1mwr9NEKLiFSn21kvx l9Yo29uqfI05HWBxhk6FJzCvFzAhdoXiLkL2jKoOYnS7iACAq9EwhQlPHzxXgghuDMph E0mQ== X-Gm-Message-State: AOPr4FUPyrgnm4wstV2MWbvfoEdd6Mwt72MZ51FHp4YjvG2Qt6W3uPtwfH7Gz4uwls8ldQ== X-Received: by 10.66.62.106 with SMTP id x10mr13264108par.136.1462378454079; Wed, 04 May 2016 09:14:14 -0700 (PDT) Received: from ?IPv6:2601:601:102:bc97:8b6:4c45:7e84:a7d? ([2601:601:102:bc97:8b6:4c45:7e84:a7d]) by smtp.gmail.com with ESMTPSA id eh9sm7177230pad.47.2016.05.04.09.14.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 09:14:12 -0700 (PDT) From: Jay X-Google-Original-From: Jay References: <1462310910.16919.2.camel@gmail.com> <84bfffeb-8172-85fd-6631-d2199eb21d94@redhat.com> <5729CC44.10601@redhat.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <636B78F0-B2D2-44B6-97D6-8F4C832EEC12@gmail.com> Cc: Andrew Haley , Richard Henderson , "libffi-discuss@sourceware.org" Subject: Re: Avoid stack/heap executable memory Date: Wed, 04 May 2016 16:14:00 -0000 To: Anthony Green X-IsSubscribed: yes X-SW-Source: 2016/txt/msg00021.txt.bz2 That is quite slow, incurring no-execute traps.=20 - Jay On May 4, 2016, at 5:42 AM, Anthony Green wrote: > Can't there be special kernel support for this kind of situation? > Like https://pax.grsecurity.net/docs/emutramp.txt >=20 > (resent because original was bounced by sourceware) >=20 > AG >=20 > 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 tha= t (at >>> least for ELF with symbol versioning), and also preserve the API. Of c= ourse, >>> there's a *lot* that can be cleaned up if we're willing to change the A= PI... >>=20 >> 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. >>=20 >> 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. >>=20 >> Andrew.