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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 25972C433DF for ; Wed, 29 Jul 2020 13:29:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 01DA920829 for ; Wed, 29 Jul 2020 13:29:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aRWtLfuQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727095AbgG2N3k (ORCPT ); Wed, 29 Jul 2020 09:29:40 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:30448 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726365AbgG2N3j (ORCPT ); Wed, 29 Jul 2020 09:29:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596029378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pHdy6Zb9Xi6Br1uklysJIGNGzShuC9IUN8gmmUSKfJ8=; b=aRWtLfuQT+4jdgoCsYV/8Kohq6UzLvVlKez2chiloW2tblAG/Uy0mBhIe2G+HlU+GcjQLU aLl1rhnwhQDuIxfbAid2URxFc6mkOAYtEIQZt41QiBfFG2vcAEEZa6XqjSyDAcyRINkOb2 CJM7c7PBLWnkxot6U5aGSeB2RzQLc8Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-185-oUnvNmSeOLyVa6xnjYceCQ-1; Wed, 29 Jul 2020 09:29:36 -0400 X-MC-Unique: oUnvNmSeOLyVa6xnjYceCQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EE5481902EA0; Wed, 29 Jul 2020 13:29:34 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-29.ams2.redhat.com [10.36.113.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B422869327; Wed, 29 Jul 2020 13:29:32 +0000 (UTC) From: Florian Weimer To: Andy Lutomirski Cc: madvenka@linux.microsoft.com, 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> Date: Wed, 29 Jul 2020 15:29:31 +0200 In-Reply-To: (Andy Lutomirski's message of "Tue, 28 Jul 2020 10:31:59 -0700") Message-ID: <87pn8eo3es.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski: > This is quite clever, but now I=E2=80=99m wondering just how much kernel = help > is really needed. In your series, the trampoline is an non-executable > page. I can think of at least two alternative approaches, and I'd > like to know the pros and cons. > > 1. Entirely userspace: a return trampoline would be something like: > > 1: > pushq %rax > pushq %rbc > pushq %rcx > ... > pushq %r15 > movq %rsp, %rdi # pointer to saved regs > leaq 1b(%rip), %rsi # pointer to the trampoline itself > callq trampoline_handler # see below > > You would fill a page with a bunch of these, possibly compacted to get > more per page, and then you would remap as many copies as needed. libffi does something like this for iOS, I believe. The only thing you really need is a PC-relative indirect call, with the target address loaded from a different page. The trampoline handler can do all the rest because it can identify the trampoline from the stack. Having a closure parameter loaded into a register will speed things up, of course. I still hope to transition libffi to this model for most Linux targets. It really simplifies things because you don't have to deal with cache flushes (on both the data and code aliases for SELinux support). But the key observation is that efficient trampolines do not need run-time code generation at all because their code is so regular. Thanks, Florian 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,URIBL_BLOCKED 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 58355C433DF for ; Wed, 29 Jul 2020 13:31:25 +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 223D620809 for ; Wed, 29 Jul 2020 13:31:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="0T75KHHD"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aRWtLfuQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 223D620809 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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=9eZS0/D44UDshqes95GMO1O+kE0FTaP5wGXvSkvrHx8=; b=0T75KHHDoCY9kpEik1L7JdLV1 QYFZmZxLpI7BYBs0kWKagrhNQUWMw98/P/nh1U6NozumnX5p7QzSQG43wRsF0knHCuqQNcLvwoN6b GTgAwPfl6JDK/O266iyigLPzpQA0ikznresIci31mqEvgBFuZEo87w/6pFruOeVLFmCInOrlYwRSY 9gJQwltOmOHNcfFQcZJ7/EJEql7/h6rH3gyrbM7J2E4LBGkLy29i/Whd2eU2QNxPfI3rP4X9cMdy6 hVTQDJGelOLZAzpeKSTSY2GzyYAXUzr4mTZ+wa4v3qnzrjD8zTRJ449VKUNmnwpH7fTrnjeZE7SHS ib+PzaWcA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0m9S-0004iE-DE; Wed, 29 Jul 2020 13:29:46 +0000 Received: from us-smtp-1.mimecast.com ([207.211.31.81] helo=us-smtp-delivery-1.mimecast.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0m9P-0004gq-Gx for linux-arm-kernel@lists.infradead.org; Wed, 29 Jul 2020 13:29:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596029378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pHdy6Zb9Xi6Br1uklysJIGNGzShuC9IUN8gmmUSKfJ8=; b=aRWtLfuQT+4jdgoCsYV/8Kohq6UzLvVlKez2chiloW2tblAG/Uy0mBhIe2G+HlU+GcjQLU aLl1rhnwhQDuIxfbAid2URxFc6mkOAYtEIQZt41QiBfFG2vcAEEZa6XqjSyDAcyRINkOb2 CJM7c7PBLWnkxot6U5aGSeB2RzQLc8Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-185-oUnvNmSeOLyVa6xnjYceCQ-1; Wed, 29 Jul 2020 09:29:36 -0400 X-MC-Unique: oUnvNmSeOLyVa6xnjYceCQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EE5481902EA0; Wed, 29 Jul 2020 13:29:34 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-29.ams2.redhat.com [10.36.113.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B422869327; Wed, 29 Jul 2020 13:29:32 +0000 (UTC) From: Florian Weimer To: Andy Lutomirski Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor References: <20200728131050.24443-1-madvenka@linux.microsoft.com> Date: Wed, 29 Jul 2020 15:29:31 +0200 In-Reply-To: (Andy Lutomirski's message of "Tue, 28 Jul 2020 10:31:59 -0700") Message-ID: <87pn8eo3es.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200729_092943_595541_5D3A91CD X-CRM114-Status: GOOD ( 16.33 ) 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 , madvenka@linux.microsoft.com, LSM List , Linux FS Devel , linux-integrity , linux-arm-kernel Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org KiBBbmR5IEx1dG9taXJza2k6Cgo+IFRoaXMgaXMgcXVpdGUgY2xldmVyLCBidXQgbm93IEnigJlt IHdvbmRlcmluZyBqdXN0IGhvdyBtdWNoIGtlcm5lbCBoZWxwCj4gaXMgcmVhbGx5IG5lZWRlZC4g SW4geW91ciBzZXJpZXMsIHRoZSB0cmFtcG9saW5lIGlzIGFuIG5vbi1leGVjdXRhYmxlCj4gcGFn ZS4gIEkgY2FuIHRoaW5rIG9mIGF0IGxlYXN0IHR3byBhbHRlcm5hdGl2ZSBhcHByb2FjaGVzLCBh bmQgSSdkCj4gbGlrZSB0byBrbm93IHRoZSBwcm9zIGFuZCBjb25zLgo+Cj4gMS4gRW50aXJlbHkg dXNlcnNwYWNlOiBhIHJldHVybiB0cmFtcG9saW5lIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlOgo+ Cj4gMToKPiBwdXNocSAlcmF4Cj4gcHVzaHEgJXJiYwo+IHB1c2hxICVyY3gKPiAuLi4KPiBwdXNo cSAlcjE1Cj4gbW92cSAlcnNwLCAlcmRpICMgcG9pbnRlciB0byBzYXZlZCByZWdzCj4gbGVhcSAx YiglcmlwKSwgJXJzaSAjIHBvaW50ZXIgdG8gdGhlIHRyYW1wb2xpbmUgaXRzZWxmCj4gY2FsbHEg dHJhbXBvbGluZV9oYW5kbGVyICMgc2VlIGJlbG93Cj4KPiBZb3Ugd291bGQgZmlsbCBhIHBhZ2Ug d2l0aCBhIGJ1bmNoIG9mIHRoZXNlLCBwb3NzaWJseSBjb21wYWN0ZWQgdG8gZ2V0Cj4gbW9yZSBw ZXIgcGFnZSwgYW5kIHRoZW4geW91IHdvdWxkIHJlbWFwIGFzIG1hbnkgY29waWVzIGFzIG5lZWRl ZC4KCmxpYmZmaSBkb2VzIHNvbWV0aGluZyBsaWtlIHRoaXMgZm9yIGlPUywgSSBiZWxpZXZlLgoK VGhlIG9ubHkgdGhpbmcgeW91IHJlYWxseSBuZWVkIGlzIGEgUEMtcmVsYXRpdmUgaW5kaXJlY3Qg Y2FsbCwgd2l0aCB0aGUKdGFyZ2V0IGFkZHJlc3MgbG9hZGVkIGZyb20gYSBkaWZmZXJlbnQgcGFn ZS4gIFRoZSB0cmFtcG9saW5lIGhhbmRsZXIgY2FuCmRvIGFsbCB0aGUgcmVzdCBiZWNhdXNlIGl0 IGNhbiBpZGVudGlmeSB0aGUgdHJhbXBvbGluZSBmcm9tIHRoZSBzdGFjay4KSGF2aW5nIGEgY2xv c3VyZSBwYXJhbWV0ZXIgbG9hZGVkIGludG8gYSByZWdpc3RlciB3aWxsIHNwZWVkIHRoaW5ncyB1 cCwKb2YgY291cnNlLgoKSSBzdGlsbCBob3BlIHRvIHRyYW5zaXRpb24gbGliZmZpIHRvIHRoaXMg bW9kZWwgZm9yIG1vc3QgTGludXggdGFyZ2V0cy4KSXQgcmVhbGx5IHNpbXBsaWZpZXMgdGhpbmdz IGJlY2F1c2UgeW91IGRvbid0IGhhdmUgdG8gZGVhbCB3aXRoIGNhY2hlCmZsdXNoZXMgKG9uIGJv dGggdGhlIGRhdGEgYW5kIGNvZGUgYWxpYXNlcyBmb3IgU0VMaW51eCBzdXBwb3J0KS4KCkJ1dCB0 aGUga2V5IG9ic2VydmF0aW9uIGlzIHRoYXQgZWZmaWNpZW50IHRyYW1wb2xpbmVzIGRvIG5vdCBu ZWVkCnJ1bi10aW1lIGNvZGUgZ2VuZXJhdGlvbiBhdCBhbGwgYmVjYXVzZSB0aGVpciBjb2RlIGlz IHNvIHJlZ3VsYXIuCgpUaGFua3MsCkZsb3JpYW4KCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51 eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5v cmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 04A0BC433DF for ; Wed, 29 Jul 2020 13:29:59 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 4E4B720809 for ; Wed, 29 Jul 2020 13:29:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="a87pl4HM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E4B720809 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-19488-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 32764 invoked by uid 550); 29 Jul 2020 13:29:51 -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 32738 invoked from network); 29 Jul 2020 13:29:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596029379; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pHdy6Zb9Xi6Br1uklysJIGNGzShuC9IUN8gmmUSKfJ8=; b=a87pl4HMfaXWliXa31GsL2U7GN8t5X2anfNGpSltIBSWXwRuKWabRl6LlrM2zJmZFgXdcx 8ax0gjqpTcPEG9IR0wTgUoXfA6uUmv1Ca6fGk5D3rKKVTfy/2hgUGPOWTrG/e+tAexFkSu Q3PTQOyFJ5Hi1ACh837maJaoVcJnsew= X-MC-Unique: oUnvNmSeOLyVa6xnjYceCQ-1 From: Florian Weimer To: Andy Lutomirski Cc: madvenka@linux.microsoft.com, 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> Date: Wed, 29 Jul 2020 15:29:31 +0200 In-Reply-To: (Andy Lutomirski's message of "Tue, 28 Jul 2020 10:31:59 -0700") Message-ID: <87pn8eo3es.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 * Andy Lutomirski: > This is quite clever, but now I=E2=80=99m wondering just how much kernel = help > is really needed. In your series, the trampoline is an non-executable > page. I can think of at least two alternative approaches, and I'd > like to know the pros and cons. > > 1. Entirely userspace: a return trampoline would be something like: > > 1: > pushq %rax > pushq %rbc > pushq %rcx > ... > pushq %r15 > movq %rsp, %rdi # pointer to saved regs > leaq 1b(%rip), %rsi # pointer to the trampoline itself > callq trampoline_handler # see below > > You would fill a page with a bunch of these, possibly compacted to get > more per page, and then you would remap as many copies as needed. libffi does something like this for iOS, I believe. The only thing you really need is a PC-relative indirect call, with the target address loaded from a different page. The trampoline handler can do all the rest because it can identify the trampoline from the stack. Having a closure parameter loaded into a register will speed things up, of course. I still hope to transition libffi to this model for most Linux targets. It really simplifies things because you don't have to deal with cache flushes (on both the data and code aliases for SELinux support). But the key observation is that efficient trampolines do not need run-time code generation at all because their code is so regular. Thanks, Florian