From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22B58C433E3 for ; Sun, 2 Aug 2020 13:57:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 04D7320759 for ; Sun, 2 Aug 2020 13:57:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725952AbgHBN5p (ORCPT ); Sun, 2 Aug 2020 09:57:45 -0400 Received: from albireo.enyo.de ([37.24.231.21]:57926 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725290AbgHBN5p (ORCPT ); Sun, 2 Aug 2020 09:57:45 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1k2EUc-0007uG-D1; Sun, 02 Aug 2020 13:57:38 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1k2EUZ-0006B6-7g; Sun, 02 Aug 2020 15:57:35 +0200 From: Florian Weimer To: "Madhavan T. Venkataraman" Cc: Andy Lutomirski , Kernel Hardening , Linux API , linux-arm-kernel , Linux FS Devel , linux-integrity , LKML , LSM List , Oleg Nesterov , X86 ML Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com> <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> Date: Sun, 02 Aug 2020 15:57:35 +0200 In-Reply-To: <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> (Madhavan T. Venkataraman's message of "Fri, 31 Jul 2020 12:13:49 -0500") Message-ID: <87o8nttak0.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Madhavan T. Venkataraman: > Standardization > --------------------- > > Trampfd is a framework that can be used to implement multiple > things. May be, a few of those things can also be implemented in > user land itself. But I think having just one mechanism to execute > dynamic code objects is preferable to having multiple mechanisms not > standardized across all applications. > > As an example, let us say that I am able to implement support for > JIT code. Let us say that an interpreter uses libffi to execute a > generated function. The interpreter would use trampfd for the JIT > code object and get an address. Then, it would pass that to libffi > which would then use trampfd for the trampoline. So, trampfd based > code objects can be chained. There is certainly value in coordination. For example, it would be nice if unwinders could recognize the trampolines during all phases and unwind correctly through them (including when interrupted by an asynchronous symbol). That requires some level of coordination with the unwinder and dynamic linker. A kernel solution could hide the intermediate state in a kernel-side trap handler, but I think it wouldn't reduce the overall complexity. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2832FC433DF for ; Sun, 2 Aug 2020 13:59:40 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E8F7B206DA for ; Sun, 2 Aug 2020 13:59:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rxW61jZn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8F7B206DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=64+1FPbAhH5AHgvjDMFFrBJ701GS88A+rEX/5VX7g6E=; b=rxW61jZnDF1JAAfQz7O+gom3s iJAV7XiuqKMMZOJtRGzckVi0j55vZTzZojgXDqS+rYJkFrTq6vi048jZh1Qw6BokHwVUmx3QMtTwR YEqeO4sAYvYhVxxNUWeVJLk4XJJcSzLIYCJGEmwP6tnD4wqFrW/NjtnnFvDdAzwLWm1N5I8Yhs12a dVTPgmzzSk2L3Qp/PXGgBvfb843+4mkrI9JKIAnsab9Na8hJ4IHkjQ7lvh307zFQ0fYq3utu2rEez +zsLfydUl5Nco/va1qRgKXqqX1ECzl1LDPJquNELEqMcW7gJgLJ4vhR3r7y8pP/VtU0KdLzYfpzIM X7sFFQ9ug==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2EUs-0005i1-73; Sun, 02 Aug 2020 13:57:54 +0000 Received: from albireo.enyo.de ([37.24.231.21]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2EUp-0005gZ-Fx for linux-arm-kernel@lists.infradead.org; Sun, 02 Aug 2020 13:57:52 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1k2EUc-0007uG-D1; Sun, 02 Aug 2020 13:57:38 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1k2EUZ-0006B6-7g; Sun, 02 Aug 2020 15:57:35 +0200 From: Florian Weimer To: "Madhavan T. Venkataraman" Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com> <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> Date: Sun, 02 Aug 2020 15:57:35 +0200 In-Reply-To: <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> (Madhavan T. Venkataraman's message of "Fri, 31 Jul 2020 12:13:49 -0500") Message-ID: <87o8nttak0.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200802_095751_551448_A2A80A4C X-CRM114-Status: GOOD ( 16.10 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kernel Hardening , Linux API , X86 ML , LKML , Oleg Nesterov , LSM List , Andy Lutomirski , Linux FS Devel , linux-integrity , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Madhavan T. Venkataraman: > Standardization > --------------------- > > Trampfd is a framework that can be used to implement multiple > things. May be, a few of those things can also be implemented in > user land itself. But I think having just one mechanism to execute > dynamic code objects is preferable to having multiple mechanisms not > standardized across all applications. > > As an example, let us say that I am able to implement support for > JIT code. Let us say that an interpreter uses libffi to execute a > generated function. The interpreter would use trampfd for the JIT > code object and get an address. Then, it would pass that to libffi > which would then use trampfd for the trampoline. So, trampfd based > code objects can be chained. There is certainly value in coordination. For example, it would be nice if unwinders could recognize the trampolines during all phases and unwind correctly through them (including when interrupted by an asynchronous symbol). That requires some level of coordination with the unwinder and dynamic linker. A kernel solution could hide the intermediate state in a kernel-side trap handler, but I think it wouldn't reduce the overall complexity. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95AFFC433E0 for ; Sun, 2 Aug 2020 13:58:02 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id EEAEA206DA for ; Sun, 2 Aug 2020 13:58:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EEAEA206DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-19512-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 22077 invoked by uid 550); 2 Aug 2020 13:57:54 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 22057 invoked from network); 2 Aug 2020 13:57:54 -0000 From: Florian Weimer To: "Madhavan T. Venkataraman" Cc: Andy Lutomirski , Kernel Hardening , Linux API , linux-arm-kernel , Linux FS Devel , linux-integrity , LKML , LSM List , Oleg Nesterov , X86 ML Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor References: <20200728131050.24443-1-madvenka@linux.microsoft.com> <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com> <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> Date: Sun, 02 Aug 2020 15:57:35 +0200 In-Reply-To: <46a1adef-65f0-bd5e-0b17-54856fb7e7ee@linux.microsoft.com> (Madhavan T. Venkataraman's message of "Fri, 31 Jul 2020 12:13:49 -0500") Message-ID: <87o8nttak0.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain * Madhavan T. Venkataraman: > Standardization > --------------------- > > Trampfd is a framework that can be used to implement multiple > things. May be, a few of those things can also be implemented in > user land itself. But I think having just one mechanism to execute > dynamic code objects is preferable to having multiple mechanisms not > standardized across all applications. > > As an example, let us say that I am able to implement support for > JIT code. Let us say that an interpreter uses libffi to execute a > generated function. The interpreter would use trampfd for the JIT > code object and get an address. Then, it would pass that to libffi > which would then use trampfd for the trampoline. So, trampfd based > code objects can be chained. There is certainly value in coordination. For example, it would be nice if unwinders could recognize the trampolines during all phases and unwind correctly through them (including when interrupted by an asynchronous symbol). That requires some level of coordination with the unwinder and dynamic linker. A kernel solution could hide the intermediate state in a kernel-side trap handler, but I think it wouldn't reduce the overall complexity.